Testwiki:Properties for deletion/Archive/2016

Template:P

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

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

Template:Ping you provided incorrect discussion link. It is about different property. -- Vlsergey (talk) 20:15, 16 June 2015 (UTC)

Template:Ping This property can help to describe functions whose domains are too complicated, and maybe not notable by themselves. It is not used much at the moment, but functions (e.g. in set-theoretic sense) are widely used in mathematics, so I think that it may be potentially useful. Danneks (talk) 18:22, 3 June 2015 (UTC)

Template:Ping It's the A set in this mathworld definition. It's commonly used for example for the inverse function on the real, who has no value in R for 0, but still has R as input set, for example. The real domain of the function is Template:Q'. TomT0m ^(talk) 11:22, 6 June 2015 (UTC)

what is the difference between Template:P and Template:P? Can you provide an example when Template:P is not enought? -- Vlsergey (talk) 20:15, 16 June 2015 (UTC)

Template:Ping It's done, see my previous message. TomT0m ^(talk) 20:49, 16 June 2015 (UTC)

Template:Ping let me make it clear. You want to express that Template:C and Template:C, right? But we have Template:C. Why do we need to duplicate that in function itself? -- Vlsergey (talk) 20:55, 16 June 2015 (UTC)

Template:Ping One can be used when we speak of a relation on any sets to any set, not only to functions. For example a database, when a customer can be registered but has not yet bought anything, or a complicated function like 1/(x-1)(x-2)(x-3). The input set of the relation beetween customer and transactions would still be customer, but some may have no relations at all. domain is clearly out of scope here. input set can be applied to function. It's unlikely that the item R minus {1,2,3} will be created either. TomT0m ^(talk) 21:03, 16 June 2015 (UTC)

Template:Ping okay, i understood about math functions. Still this can be expressed with qualifiers (R except...). For database relationship it is still not clear for me. What is item and why we can't put "customer" into Template:P? (with broader Template:P definition of course). It would be better to provide an example with actual Wikidata entries. I care little about abstract concepts, sorry. Vlsergey (talk) 21:12, 16 June 2015 (UTC)

I have many example of non total functions, Template:Q' involves a HALT function which is from programs to 1,0 which has programs as input set but is undecidable. Template:Q' provides other examples. The notion of domain is also non applicable for relations ( Template:Q' ) like 1<2 or other Template:Q'. It's well know that functions can be seen as binary relations iRo with i (input set) as their domain and o (output set) as their range. TomT0m ^(talk) 07:21, 17 June 2015 (UTC)

We may speak of a function from R² to R² when we really mean one from U in R² to V in R². In my opinion this is important for characterizing the function type. For example I want all 2D vector fields, no matter what particular subset of R² they are defined on, to be noted as such. So in short, Template:Keep.--Jasper Deng (talk) 22:06, 13 August 2015 (UTC)

Jasper Deng: References would help. --Succu (talk) 22:16, 13 August 2015 (UTC)

Template:Ping Do you even understand what I'm saying?--Jasper Deng (talk) 22:52, 13 August 2015 (UTC)

Jasper Deng: Mind to translate R², U and V for beeings not living in a Template:Q? Please give a clear definition of the mathematical terms Template:P and Template:P. What exactly renders them to be different? And stop guessing! --Succu (talk) 20:49, 14 August 2015 (UTC)

Template:Ping I don't think you understand the level of math at which I'm talking since I'm not talking about general vector spaces. But out of these two, only domain is well-defined. In my comment, R² is the "input set".--Jasper Deng (talk) 06:10, 15 August 2015 (UTC)

Template:Ping Are you satisfied with the current discussion or do you have other questions ? If you still don't understand, it's maybe useful to say that it's a notion we study on secondary school in maths courses, so a not so advanced one. Maybe pinging other mathematicians like Template:Ping for support will help :) I'll left a message on the french math wikiproject, it's a cool opportunity to communicate around Wikidata. author  TomT0m / talk page 09:07, 15 August 2015 (UTC)

It's difficult for me to write english. So please, be kind with me and improve my text. There is a difference between set of departure and domain. The set of departure is defined for a binary relation(Q130901). See this definition for example. So, the set of departure of a partial function(Q1756942) is defined like the set of departure of a binary relation. Template:PingIn Deutsch, set of departure = Vorbereich und domain = Definitionsbereich[1]. For exemple, the function f(x)=1/x is a partial function whose set of departure is R. It's a total function[2] whose domain is R - {0}. Mostly, the domain is the better property of a function but if we cannot precise the domain , the set of departure is a good property indeed. Its also a good property for classes of functions like functions of a real variable(Q861681) whose set of departure is R and domain a subset of R. We may delete set of departure-property and put in domain-property the value set of X but it would be a pity since the notion of set of departure does exist. Template:Keep for me HB (talk) 13:57, 15 August 2015 (UTC)

Nachträglich anpingen funktioniert nicht, aber ich vermute mal er bekommt's auch so mit. --Nenntmichruhigip (talk) 16:11, 15 August 2015 (UTC)

HB: Thank you for your explanation. I'd tried to understand the problem, and failed because I think I learned other German terms for these at school. But that’s a while ago. --Succu (talk) 15:25, 16 August 2015 (UTC)

page I am familiar with set theory. That isn't where my confusion lies. All the wonderful discussion of functions above is, as far as I am concerned, irrelevant because it doesn't have an example of a practical example here on wikidata - where we call the functions "properties" and the sets "classes". You need to give an example of an actual statement where it is useful to state the 'input set' of an item instead of stating the 'domain'.

We also need an example where 'input set' is useful for making a statement about a property. Joe Filceolaire (talk) 20:36, 16 August 2015 (UTC)

Template:Ping Properties are not functions, they are Template:Q' :) And in relations it is not required at all that any member of the input set or the output set are members of the relation at all. When we say that the domain of a property is "human beeing" this does not imply at all that humans has a value for this property. I know it's not that easy to find examples, but I'm pretty sure if I need this property in the future and that I'll have to pass to the whole review process, I'll be sad and I'm not sure I'll attempt. It's so long and boring ... On the other hand a ready property just in case for a defined notion is not really costly, that's why I presented a consistent plan with domain/input set/image/output set initially that seemed reasonable and pretty well known in maths. Maybe 6 months, and it's still not over. This implies I'm totally on something else now. So much discussion for a such small problem is a love breaker. I know there is Bonnie and Clyde problems in advanced maths for generalized functions like Template:Q can have pretty complex domains (discontinuous on the negative numbers for example) although its input set in clearly the complex numbers. I would not be able to express this easily if I want to. This has an impact on potential queries : If I want to know all functions on the complexes in math, if the Domain is C-Z or whatever, the query will be more complex to implement for example. author  TomT0m / talk page 12:06, 17 August 2015 (UTC)

Template:Keep - Template:Ping First of all, sorry for my English. All the values in domain must have a correspondent value in image set. e.g. the domain of the function "VIAF ID" is a set which all the persons that have a VIAF ID. I, for one, can not be in this group, because I do not have a VIAF ID. But the entry set of the "VIAF ID" may be all the Template:P Template:Q, since there can be an element of the entry set for which there is no corresponding image. Almondega (talk) 02:03, 18 August 2015 (UTC)

Hi and welcome on Wikidata. Looks like someone is reading my talkpage :) author  TomT0m / talk page 12:33, 18 August 2015 (UTC)

So no one can think of even one example where we should use this property rather than "domain". I'm still voting delete. Joe Filceolaire (talk) 15:05, 18 August 2015 (UTC)

Template:Ping I reread the en:Partial_function article and I found a funny example of elementary maths: the domain function that computes the difference beetween two numbers with the result in N as a range. if you take this as a partial function from NxN->N, then the domain is (x,y) such that x>y, not that easy to express :) The subclass relationship Template:Q is probably a better example. Imagine a function "smallest wrt. inclusion" with input sets A,B -> C as A and B classes, and that returns A if A is included in B, and B if converse. If neither A is included in B and B in A, then the result would be undefined. author  TomT0m / talk page 16:15, 18 August 2015 (UTC)

Template:Ping. This property is already used in Template:Q and Template:Q. What would put as domain in theses cases? HB (talk) 16:54, 18 August 2015 (UTC)

Thank you HB. At last a concrete example. Now if you can just explain to me why "domain:real numbers" is incorrect then we will finally be getting somewhere. Joe Filceolaire (talk) 15:50, 19 August 2015 (UTC)

Template:Ping The domain of a function, by definition, is the set of all "permitted inputs", for which the function has a value. The cotangent function, for example, is not defined at zero, because $\frac{1}{0}$ is not a number. It can be regarded as a point on the Riemann sphere, but it would be another function. Danneks (talk) 17:36, 19 August 2015 (UTC)

Thank you Danneks and now we are almost there. So the Domain is the set that includes all 'permitted inputs' and excludes all 'non-permitted inputs'. (I presume that is what you were trying to say above) while the input set is the set that includes all 'permitted inputs' and may also include some 'non-permitted inputs'. Is that it HB, TomT0m?

Such a pity no one said this earlier. If this is the definition then it sounds like we need another property to identify non-permitted inputs' wherever we use 'input set' so we can say <tangent - 'input set:real numbers', 'non-permitted inputs:90°, 270°'>. Joe Filceolaire (talk) 11:32, 20 August 2015 (UTC)

Template:Ping We might better need properties like Union of / intersection of / set substraction to express more complicated sets, like for example real numbers minus integers or something. This is more general. And "non permitted inputs" is not really general enough as there is infinite sets involved for example in the example HB showed. In the end if we are able to express the set, we would just need domain and create an item for the set. Which is not a goal we can easily achive, at least with current Wikidata status, as we try to explain since the beginning of this discussion. Can we settle this and close this discussion ? As you're the proposer this would be cool you removes the proposal so we can move on :) author  TomT0m / talk page 14:46, 27 October 2015 (UTC)

TomT0m: Vote changed per discussion above. As a 'non-permitted inputs' property can have multiple values and can link to sets as well as to individual values I still think it would work. multiple values = Union of. Value with qualifier = intersection of.

Template:Ping This seems not really robust to me. Wikidata's semantics about multiple values is somewhat not really clear. If we have two date of birth for example we can't really interpret that as a union but more as an either date1 or date2 situation, we can't assume there might not be other values because of the "open world" issue (that's the same reason I proposed a qualifier on the "union of/union" proposal who is still on hold) ... Does not seems to be right to rely on that to model maths :) Plus we would need to discriminate sets and member values. This needs more thinking and more care to be done right. author  TomT0m / talk page 20:42, 27 October 2015 (UTC)

You're probably right. Either way it's a separate discussion.

Anyway I have changed the description of 'Template:P' so it matches the discussion here. Joe Filceolaire (talk) 20:03, 27 October 2015 (UTC)

This is another topic but "permitted value" does not really make mathematical sense, we're not talking of computational functions but of mathematical one, so the function is simply undefined for those values. Not sure this is clear for everyone ;) author  TomT0m / talk page 20:42, 27 October 2015 (UTC)

TomT0m If 'non-permitted values' is incorrect then can you come up with a better phrase for the set of values that are included in the 'input set' but which are not included in the 'domain'? We need to include such a phrase in the description of 'input set' to make it clear how 'input set' is different from 'domain'. How about "values for which the function is undefined"? The description for Template:P can then be

a superset of the domain of a function or relation that may include some inputs for which the function is not defined. Use Domain (P1568) for the set of inputs for which the function is defined.

OK? Then we can create a new property labelled "Values for which the function is not defined" to work alongside Template:P. Joe Filceolaire (talk) 03:45, 28 October 2015 (UTC)

Template:Keep. I have slightly modified the description to a superset of the domain of a function or relation that may include some inputs for which the function is not defined; to specify the set of only those inputs for which the function is defined use domain (P1568). By the way, the number of items using this property is rising. ;-) Can we close this PfD now? Petr Matas 08:09, 4 January 2016 (UTC)

The proposed property "Values for which the function is not defined" would have data type Item and its value would be equal to Template:P minus Template:P, which is no simpler than Template:P. Furthermore, the value would depend on both Template:P and Template:P, whereas the latter two properties are to some extent independent. So I would not vote for such property. Petr Matas 08:09, 4 January 2016 (UTC)

Language of Instruction / Medium of instruction

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

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

Template:Q

Ya existe éste elemento en Q7383978--Cygomezm (talk) 21:28, 10 February 2016 (UTC)

Does not belong here, Template:Merged and redirected. Matěj Suchánek (talk) 15:17, 11 February 2016 (UTC)

Property:P2569

Premature - api doesn't work either. We can undelete this once it's available.
--- Jura 16:16, 10 March 2016 (UTC)

Template:Vote delete - Unused and won't be usable anytime soon. (Relies on precision = 13, which isn't accepted by GUI nor by API). Mbch331 (talk) 06:49, 11 March 2016 (UTC)

Template:PfD

Created out-of-process, per Wikidata:Project chat#P217 - should it be broadened?--Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:50, 16 March 2016 (UTC)

Done, as a revert of my own creation. Ajraddatz (talk) 18:59, 16 March 2016 (UTC)

Template:PfD

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

Any examples? Sjoerd de Bruin (talk) 16:18, 4 August 2015 (UTC)

Well, I pretty much see this used as in black/white for example, which is not really a good example of meaning, but nobody would say that http://html-color-codes.info/ yellow FFFF00 is the opposite of blue 0000FF as 000000 (black) is the opposite of FFFFFF (white). Is "love" the "opposite" of "hate" ? We actually also speaks of "love"/"hate" relationships. We should take some example and study if there is anything to so with them at all. author  TomT0m / talk page 09:22, 15 August 2015 (UTC)

"Template:Q" is about having two opposite emotions for the same object. Things like "war" or "indifference" are sometimes said to be opposite to specific cases of "love" in specific expressions, but Template:Q is about the most generic "love". --AVRS (talk) 08:49, 24 August 2015 (UTC)

I agree this does not make sense in a huge majority of cases. A really better definition would be based on the "complement" notion of the set theory. If we can divide (lets take a bad example) the human action set into good actions and evil actions, and that an action is either good or bad, but nether both, then the "good action" class is the complement of the "bad action" class in the "human action" class. In the same spirit I proposed strongly defined "union of" and "disjoint union of" properties (see Template:Property proposal link). author  TomT0m / talk page 16:47, 4 August 2015 (UTC)

Some example taken from https://www.wikidata.org/wiki/Special:WhatLinksHere/Property:P461 Man / woman : the opposite, really ? Big Bang, Big Crunch ? Internet / extranet ?

What's true is that if we take all human, then remove all women, we get all men, and conversely. In math we say that men complements women in the set of human. This has a meaning, and is a proposed property we could work with, for example, but I would not know how an intranet is the opposite of internet. author  TomT0m / talk page 09:22, 15 August 2015 (UTC)

Except the complement of all women is all men + all intersex. --Izno (talk) 18:34, 15 August 2015 (UTC)

Template:Ping Yes, it's good to find good and accurate examples :) Actually it's the proposed Template:PP disjoint union of (partitioned into?) that would fit here : Template:C. It's not approved yet thought, although there is a lot of example of use cases here. author  TomT0m / talk page 09:29, 16 August 2015 (UTC)

Delete. I agree with the proposer's rationale. --Izno (talk) 18:34, 15 August 2015 (UTC)

Not sure if the property is terribly useful, but that can be said about a few others as well.

For some of the pairs, it might be worth adding a qualifier to indicate what differentiates/opposes them. --- Jura 07:03, 16 August 2015 (UTC)

• Template:Comment The creation discussion (Wikidata:Property_proposal/Archive/6#P461) was less than fulsome, though indicated that there use cases for articles without giving examples. Template:Ping in case they wish to contribute.  — billinghurst sDrewth 05:58, 21 August 2015 (UTC)

Concerning colors and man/woman, there may be a property specifying the "frame of reference" (similar to Template:P). I don't know about color models, but there is "Template:Q". --AVRS (talk) 08:49, 24 August 2015 (UTC)

Q5530970 even has a French label. "frame of reference" could be a good start for the qualifier. --- Jura 07:02, 26 August 2015 (UTC)

I think that the "opposite" could be interesting for a property, but it has been used weirdly. Perhaps the scope is too broad. I like the suggestion by Jura1 to indicate somehow in what respect the pair of items represent opposites. I was surprised to find opposite pairs like Template:Q and Template:Q, which are merely antipodes on the globe. It is clarified with a Template:P Template:Q as a qualifier, I'm not sure it is the right way to indicate it, but something like that should be added, by obligation IMHO. If so, I say Template:Keep. Lymantria (talk) 17:51, 29 August 2015 (UTC)

There is just such a qualifier: Template:P, and I agree it should be mandatory. In your example, a better qualifying statement would be Template:P Template:Q, but "antipode" might be sensibly proposed as a subproperty of Template:P Swpb (talk) 15:20, 29 December 2015 (UTC)

• Template:Keep. Add documentation, clean up where necessary, create better properties where possible, relist if still not satisfied. --AVRS (talk) 10:44, 13 September 2015 (UTC)

• I suggest reading en:Opposite_(semantics)#Antonyms. Opposite can mean different things. Probably this property could be made more exact using qualifiers to state what kind of oposition it means in each statement, or it could be split in more precise properties. Anyway, in its present state it isn't machine-readable (as Wikidata should be) because it's need a human decide it's meaning in each item. It's more a trivial section than a fact statement - it doesn't harm but I don't see it very useful as of now.--Pere prlpz (talk) 17:47, 6 November 2015 (UTC)

  Template:Ping Everything is in the "Word" in the "pair of words". Wikidata do not speak of words at this point, this is for Wiktionary. For some cases here, we use opposite for the "complement" notion (I simplify for the example : (for simplification I just ignore the LGBT and co. cases at first) : "every human is either a man or a woman". To express this, at this point, some people on Wikidata would use "man : opposite : woman". In the proposition "Template:PP" we have the possibility to say that the set of all men and the set of all women are disjoint, and that when taken together (the union of the set of all man and all woman is the set of all human. This can be said in maths language "the set of men is the complement of the set of women in the set of human". If we add the set of all "transgender" or others as needed, we kind express this as "Human is the disjoint union of men, women, transgender, ..." author  TomT0m / talk page 18:01, 6 November 2015 (UTC)

• Template:Keep But I have encountered plenty of claims which don't make sense to me. For example, Template:Q has been claimed to be the opposite of Template:Q. Perhaps something has been lost in translation? Danrok (talk) 16:02, 18 December 2015 (UTC)
• Template:Keep, but require qualifier Template:P; create subproperties like Template:P as warranted. Swpb (talk) 15:12, 29 December 2015 (UTC)

Template:P

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

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

Template:PfD

Template:PfD

(Notifying original proposer Template:Ping and creator Template:Ping.)

Both of these properties are little used and redundant to Template:P (and sometimese Template:P) qualified by Template:P. --Yair rand (talk) 10:03, 22 December 2015 (UTC)

• Template:Vote delete per nominator's rationale. Swpb (talk) 15:38, 29 December 2015 (UTC)
• Template:Vote delete per rationale. Both properties are used only 10 times each. --Jklamo (talk) 19:36, 25 March 2016 (UTC)

Property:P1221

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

• Template:O. Template:P is clearly not "unused", and is not for Template:P. For example, Template:Q, which has this property, is a "subclass of" Template:Q and Template:Q and not an "instance of" Template:Q. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:47, 29 December 2015 (UTC)

  Template:Ping would my suggestion below change your oppose? --Izno (talk) 18:37, 12 January 2016 (UTC)

• Delete - Template:P is not the correct property of replacement, however. The correct one would be Template:Has part. The data is not used in any wiki, which means we can encourage the use of this more generic property trivially. --Izno (talk) 22:47, 29 December 2015 (UTC)
• Template:Keep: It seems its only sin is to be as yet underused. Template:P is not a valid substitute, but Template:P may work. Still, I don't see any value to deleting it. Josh Baumgartner (talk) 18:30, 5 January 2016 (UTC)
• Template:Vk Maybe underused, but clearly defined sub-property of Template:P. Using Template:P would be ambiguous, if not used with qualifiers. --Srittau (talk) 02:41, 25 March 2016 (UTC)

Property:P1887

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

• Keep and procedural close ASAP. Template:P was recently discussed on this page, also nominated by Jura1, with no support whatsoever. The discussion was closed as "keep" as recently as 17 December 2015. The claim that the property "doesn't seem to have any practical use" is utterly bogus, as is the claim that the property is "unused", and both are contradicted in that previous discussion, in comments to which Jura1 posted responses. Once again, I was not notified of this nomination. Furthermore, this renomination, when there are another 255 properties with fewer than 3 uses, appears very pointed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:19, 31 January 2016 (UTC)
  • The property was created in May 2015‎ and it's used only once. I'm sure that if this is a useful property that it can be used more? I'll check back in a couple of weeks. If it's still barely used it will probably be deleted, if it's usage is better we can keep it. Also Template:Ping Multichill (talk) 17:43, 5 February 2016 (UTC)
  • In the meantime, Pigsonthewing had another 8 weeks to find uses for this property, but apparently this wasn't possible, just as much as during the 8 weeks of the previous nomination. This despite posting 5-10 comments about the property. In the previous discussion, it wasn't even clear if the only other keep vote was supporting the property as they had another use in mind.
    --- Jura 06:22, 8 February 2016 (UTC)
    • I wasn't aware that we were up against a deadline (nor indeed that it was my personal responsibility to ensure that the deadline was met). Please can someone point out where it is documented? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:22, 10 February 2016 (UTC)
      • Deletion requests are closed after 7 days minimum.
        --- Jura 18:35, 11 February 2016 (UTC)
        • Quite. The discussion was closed as "keep" as recently as 17 December 2015. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:50, 14 February 2016 (UTC)
• Template:Keep per the lack of reason presented to do otherwise. Jura1 appears to be on some sort of mission against this property, but the same arguments were rejected in December and nothing has changed since. Thryduulf (talk: local | en.wp | en.wikt) 11:26, 11 February 2016 (UTC)
  • Yeah, I tend to clean up my stuff myself.
    --- Jura 18:35, 11 February 2016 (UTC)
    • I don't understand how that comment makes any sense as a reply to mine. Thryduulf (talk: local | en.wp | en.wikt) 02:58, 14 February 2016 (UTC)
  • It's almost a month ago I left a comment here and this property is only used once, it's currently on the path to the waste bin. Multichill (talk) 20:45, 29 February 2016 (UTC)
    • Despite asking in multiple places, nobody has ever explained why properties that are not presently used by many items (but which can be used by many) are actually a problem that needs solving. Until that question is answered satisfactorily I stand by my firm opposition to deletion. Thryduulf (talk: local | en.wp | en.wikt) 10:49, 1 March 2016 (UTC)
      • Wikidata:Project_chat#Property_proposals_need_attention. Please help with the cleanup of the list mentioned there if you proposed or supported the creation of any properties listed there. Personally, I think I should be doing this type of cleanup if it was me. If properties are actually needed, they could be re-created.
        --- Jura 11:15, 1 March 2016 (UTC)
        • You will note that I am marked as doing work on the one property on that list I proposed, but this still does not answer the question. Thryduulf (talk: local | en.wp | en.wikt) 17:51, 1 March 2016 (UTC)
          • I didn't say I expect you to clean up P1887. I'm doing that already. As for the unused properties mentioned on project chat, please help us assess them on User:Addshore/Identifiers/0.
            --- Jura 17:55, 1 March 2016 (UTC)
            • What question do you think Thryduulf is asking? Dancter (talk) 19:09, 1 March 2016 (UTC)
              • How can they can help to not make unused problems an issue?
                --- Jura 19:17, 1 March 2016 (UTC)
                • No, the question I am asking is "Why are unused properties an issue?". Thryduulf (talk: local | en.wp | en.wikt) 19:22, 1 March 2016 (UTC)

Template:Vote deleteTemplate:Ping Personally, I don't like dormant properties because they cause work but don't help anybody. Labels and descriptions have to be translated, property constraints have to be defined and the violation reports should be watched. I don't know how often Template:P is misused, but there are certainly dormant properties which are wrongly used on a regular basis (my favorite is Template:P). That is work which ends in smoke. In addition, if I don't understand the documentation of a property (and I don't understand the documentation of P1887), I first look at items which are using the property. But this is not possible if it is a dormant property. --Pasleim (talk) 21:46, 2 March 2016 (UTC)

Thank you for the answer, but I don't understand why a property being dormant or not has any impact on whether it will be misused or not? If the documentation is unclear then surely the answer is to improve the documentation rather than delete the property? If something is frequently misused then this and the property that should be used need to be looked at to see if the documentation or label could be improved, regardless of how well used the property is. Labels and descriptions translated now mean they don't have to be done again later - unless the property is deleted, in which case the work needs to be done again when it is recreated. If a property is not being used, then there should not be any constraint violations for it - unless it is being misused (in which case see my previous comments). In short, none of those seem like good reasons to delete a property. Thryduulf (talk: local | en.wp | en.wikt) 00:47, 3 March 2016 (UTC)

If property is dormant or not doesn't have an impact on whether it will be misused. But undoing the wrong edits, improving the documentation to prevent wrong edits, adding translations, that's all work for nothing if the property stays dormant forever. And in case of Template:P I have to assume that it will stay dormant forever as after nine months not even the property proposer could add a second example. --Pasleim (talk) 09:14, 3 March 2016 (UTC)

There is no deadline. Why should someone have to fill a property on some arbitrary timescale? If it cannot be used or is duplicated that is very different to not presently used. It is clear from the original proposal and from the two deletion discussions that this property can be used and is not duplicative of anything, so I see absolutely no value to be gained by the deletion - particularly as nobody has presented any evidence of this actually being misused rather than just having the potential to be misused. Thryduulf (talk: local | en.wp | en.wikt) 12:50, 3 March 2016 (UTC)

Template:PfD

Seems to be a duplicate of Template:P and is used only on five items.--Thierry Caro (talk) 21:11, 1 March 2016 (UTC)

• Delete - same thing according to the descriptions. Ajraddatz (talk) 05:34, 3 March 2016 (UTC)
• 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.
  --- Jura 09:46, 3 March 2016 (UTC)
• 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. --Izno (talk) 13:58, 8 March 2016 (UTC)
• Template:Vote delete almost same meaning as Template:P, used only six times. --Jklamo (talk) 19:40, 25 March 2016 (UTC)

Property:P2653

Wrong datatype, recreating Srittau (talk) 18:46, 25 March 2016 (UTC)

done --Pasleim (talk) 19:17, 25 March 2016 (UTC)

Property:P2654

I am sorry, I will get it right eventually :( - wrong datatype again Srittau (talk) 18:47, 25 March 2016 (UTC)

done --Pasleim (talk) 19:18, 25 March 2016 (UTC)

Property:P2706

Created by error Fralambert (talk) 02:06, 6 April 2016 (UTC)

done! -- Innocent bystander (talk) 06:37, 6 April 2016 (UTC)

Wikidata example properties

• Template:P Template:Rfd links
• Template:P Template:Rfd links
• Template:P Template:Rfd links
• Template:P Template:Rfd links
• Template:P Template:Rfd links
• Template:P Template:Rfd links
• Template:P Template:Rfd links
• Template:P Template:Rfd links
• Template:P Template:Rfd links

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

I prefer keeping them. Your other approach introduces uses as qualifiers for exisiting properties. And, no, it's not appropriate to change all uses before the end of this discussion. Please undo your edits where this hasn't been done yet. --- Jura 13:00, 30 July 2015 (UTC)

Template:Ping What's wrong with "introducing uses as qualifiers for existing properties" ? We have already done this in a big way with Template:P -- see the results of eg this query tinyurl.com/qekm959 for qualifiers used on P360 statements. Jheald (talk) 17:02, 8 October 2015 (UTC)

Template:Keep, seems useful in sandboxes or in docs to have properties with some sample datatypes we can use without messing around with properties actually used for real datas, at least. author  TomT0m / talk page 09:10, 15 August 2015 (UTC)

Template:Ping There are also sandbox properties Template:P, Template:P, Template:P, Template:P, Template:P, Template:P, Template:P, Template:P --Pasleim (talk) 20:55, 16 August 2015 (UTC)

OK, then if they are useless after all, don't see don't see a good reason to oppose deletion. author  TomT0m / talk page 16:16, 18 August 2015 (UTC)

Actually, the problem mentioned remains (samples messing around with properties used for real data), especially since we can now use properties on properties. --- Jura 13:33, 20 August 2015 (UTC)

Template:Ping In that case, please strike your "keep", above, to avoid confusion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:57, 5 January 2016 (UTC)

Template:Vote delete. Reusing the property itself in the example is much clearer than using those properties. Thierry Caro (talk) 01:35, 20 August 2015 (UTC)

Template:Vote delete per andy. Joe Filceolaire (talk) 23:21, 20 August 2015 (UTC) It looks like we will need these as placeholder properties for defining rules for transitive; reflexive; etc properties. See Wikidata:WikiProject Reasoning. GZWDer: note that we will need a sandbox property for each datatype so that is pretty much all of these. Joe Filceolaire (talk) 18:44, 31 August 2015 (UTC)

Template:Ping Does Template:P satisfy this, for you? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:57, 5 January 2016 (UTC)

Redefine Template:P as a sandbox property, delete the rest--GZWDer (talk) 05:02, 26 August 2015 (UTC)

Template:Ping have you checked how they are being used? --- Jura 05:35, 26 August 2015 (UTC)

Template:Ping Their current usage should be cleared once the discussion is closed.--GZWDer (talk) 05:37, 26 August 2015 (UTC)

Template:Ping I created Template:P as sandbox property with datatype property. --Pasleim (talk) 22:10, 30 November 2015 (UTC)

Template:Ping Does Template:P satisfy this, for you? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:57, 5 January 2016 (UTC)

So what is the actual outcome of this discussion, if any? Should we stop using them? Should we replace them all? Will they be deleted? (Sorry for the noise.) Matěj Suchánek (talk) 20:36, 30 November 2015 (UTC)

I had closed this as no consensus to delete, considering it had been open for a long time with little to no discussion. I have, however, reopened it, per request, to see if any further discussion takes place.  Hazard SJ  02:29, 3 January 2016 (UTC)

Template:Vote delete Reusing the existing properties in examples is clearer and causes less confusion than the use of those properties. Already the discussion above shows that many users are confused and mistake those example properties with sandbox properties. --Pasleim (talk) 20:20, 5 January 2016 (UTC)

Template:Vote delete I agree that using the properties themselves in examples is clearer. - Nikki (talk) 19:29, 6 January 2016 (UTC)

Template:Keep use these for test/sample/sandbox data on property items. Entering samples with actual properties mixes test/sample/sandbox data into production dataset. Samples on property documentation look the same with these properties than they do with actual properties, so the clarity is the same. Using these properties makes users focus on actually defining samples, making sure they are ready to define samples.
--- Jura 19:40, 6 January 2016 (UTC)

Template:Ping I'm not sure I agree. If you look at the example Andy gave (diff), it seems to me that it doesn't "mix test/sample/sandbox data into production dataset".

The value 18049321 doesn't become a value of the property wt:P2011, it becomes a value of the qualifer pq:P2011, attached in the specific context of the exemplar property Template:P -- something which should be straightforward enough to filter out, even in the rare occasion that one were to be specifically querying for the property used in a qualifier context.

In my view this is something well worthwhile, for the clear benefit of using the immediately apparent Template:P to show how P2011 is used, rather than the much less clear Template:P syntax. Jheald (talk) 21:39, 6 January 2016 (UTC)

Template:Ping please don't change qualifiers before this deletion debate is over. Multichill (talk) 22:35, 9 January 2016 (UTC)

The two are not mutually exclusive. In any case, I merely reverted a more recent change which itself was made while this deletion proposal was taking place. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:03, 9 January 2016 (UTC)

This duplicates Jura1's comment of 30 July 2015. Double-counting should be avoided. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:03, 9 January 2016 (UTC)

Template:Vote delete as a new property creator I was confused by this for a week or two - using the actual property as a qualifier in the example is actually a good test that things are working as well as demonstrating use. I would be happy to help replacing old uses of these if there's a consensus to do that before deleting. ArthurPSmith (talk) 19:05, 14 January 2016 (UTC)

Template:Comment Months ago I wrote a script which should move some property metadata from talk pages to statements, including those examples. This discussion has however been blocking me since then. Is there any chance on closing this soon?

Advantage of using the property itself is that the value can automatically get formatted by the gadget (in the future by the software). Matěj Suchánek (talk) 12:09, 24 January 2016 (UTC)

Template:Ping Template:Tq Apparently not, despite there being only a single individual still opposing. It's farcical. :-( Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:50, 20 March 2016 (UTC)

Template:Vd Per all of the above, the continuing existence of these property leads to people using them. --Srittau (talk) 02:34, 25 March 2016 (UTC)

Template:Vote delete These properties are just confusing. --Jklamo (talk) 19:31, 25 March 2016 (UTC)

Template:Comment If that move happens, also https://www.wikidata.org/wiki/Template:List_of_properties/Row and similar templates/modules need to be updated I imagine. Laboramus (talk) 23:09, 26 March 2016 (UTC)

Template:Comment None of those properties are in use anymore. I removed the last two usages. --Srittau (talk) 23:19, 26 March 2016 (UTC) The query did not look for qualifiers. --Srittau (talk) 23:23, 26 March 2016 (UTC)

Of course, while trying to clean this up, my changes get reverted by User:Jura1. Kindergarten behaviour. --Srittau (talk) 23:49, 26 March 2016 (UTC)

Template:PfD

The BioStor author identifiers seem to have been removed from the database. For instance the example link is a dead link. --Lymantria (talk) 13:12, 8 March 2016 (UTC)

Keep. Firstly there is a notice on the BioStor home page: "Heads up! BioStor is evolving, so things will look different and some things may be missing.", so this may be temporary; and secondly, we shouldn't delete properties and data even if the original source disappears. (There is also still data to be imported from Wikipedia). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:52, 10 March 2016 (UTC)

I don't see any indication that this ID would return somehow, but see that "... some things may be missing". Keeping a property with an identifier for a website that does not use the identifier anymore, and a property that is used in no more than 8 items, IMHO is fairly useless. Lymantria (talk) 08:43, 12 March 2016 (UTC)

Created without clear consensus, but we can ask Roderic... --Succu (talk) 17:45, 16 March 2016 (UTC)

No, there was clear consensus. Both I as the proposer and Joe Filceolaire supported, and no-one objected. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:03, 18 March 2016 (UTC)

Speedy delete: There is no clear consensus as the proposer and creator suggests. BioStor is an experimental website created by Roderic D. M. Page. If the proposer and creator of this property had informed Wikidata:WikiProject Taxonomy I had objected earlier. --Succu (talk) 07:41, 19 March 2016 (UTC) Template:Ping project --Succu (talk) 07:43, 19 March 2016 (UTC)

Poppyocck. Two for, and no opposes. How is that anything other than "clear consensus"? Nor is this a taxonomic property. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:54, 19 March 2016 (UTC)

[Note: My reply is to Succu's comment, not his separately signed, outdented ping-project. The reason it is here, improperly indented, and not underneath that comment is because Succu has moved it] Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:47, 19 March 2016 (UTC)

BioStor is not an authority control for people. --Succu (talk) 14:00, 19 March 2016 (UTC)

• Template:Vd If it's dead, convert the few uses to "described at URL" (P973) and delete it. Interested parties are already not doing the necessary maintenance on it.
  --- Jura 09:51, 19 March 2016 (UTC)
  • As noted below, it's not dead. As noted above, there is still data to be imported from Wikipedia. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:09, 19 March 2016 (UTC)

Note: As predicted, BioStor author pages are available again, for example: http://direct.biostor.org/author/2234 I've modified the formatterURL accordingly. FYI, User:Lymantria. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:06, 19 March 2016 (UTC)

A Note from Roderic Page „Note that this is the OLD BioStor which will one day be switched off”. --Succu (talk) 12:20, 20 March 2016 (UTC)

At which point, we can update, or remove, the formatter URL. Until and after that "one day", these IDs remain useful data. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:30, 20 March 2016 (UTC)

New BioStor works with search results. We won't switch to that. Lymantria (talk) 07:02, 24 March 2016 (UTC)

Your comment does not contradict, much less refute, mine. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:42, 25 March 2016 (UTC)

According to Template:Q Template:Q addresses the question „does this article exist in the BHL archive?“ and is not intended to be an authority control for authors. Your template Template:Q is used exactly once. I see no reason to keep this property. --Succu (talk) 21:31, 25 March 2016 (UTC)

Congratulation on managing to cram so many straw men into one post. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:47, 27 March 2016 (UTC)

Yes, this answer rocks. But only by ignoring the intention of the websites creator. --Succu (talk) 20:24, 27 March 2016 (UTC)

Template:Vote delete this page is too experimental to be included to a serious project like Wikidata. --Pasleim (talk) 10:01, 6 April 2016 (UTC)

Template:Vote delete BioStor is an interface to BHL, with no added functionality, but just another way to access it. And indeed, this "BioStor author" is very incomplete. - Brya (talk) 18:02, 11 April 2016 (UTC)

Wow, completely missed this discussion, and in retrospect rather glad that I did. To clarify, the "author ids" in the original BioStor http://direct.biostor.org are internal database ids, and were not intended to be long term identifiers for authors. The current BioStor http://biostor.org doesn't support author ids. For those, I'd much prefer to use Template:Q, Template:Q, or, indeed, Template:Q. I sketched out one approach mapping author names to Wikipedia articles via lists of published works on Wikipedia pages here http://iphylo.blogspot.co.uk/2015/08/possible-project-mapping-authors-to.html --Rdmpage (talk) 13:48, 26 April 2016 (UTC) Template:Discussion bottom

Template:P

Template:Discussion top Template:Ping Unclear scope, using such a modeling needs a way broader discussion than Wikidata:Property_proposal/Property_metadata#formatterURL_for_Wikidata_ID. To allow further discussions, the property should be deleted for now. - Hoo man (talk) 17:04, 17 March 2016 (UTC)

I'm getting a little bit uncomfortable with Pigsonthewing closing his own requests. Sjoerd de Bruin (talk) 17:48, 17 March 2016 (UTC)

You think someone else would have reached a different conclusion? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:52, 17 March 2016 (UTC)

The discussion was open for more than a week, as required. There was one pro vote and no contra votes. Creating this property seems fine to me. --Srittau (talk) 02:52, 25 March 2016 (UTC)

• Speedy keep This was created with support, and no objections, after a lengthy period (double the requirement!) at Property proposal/Property metadata, which occurred after a separate discussion identified the need for such a property. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:51, 17 March 2016 (UTC)
  • Note discussion at Wikidata:Contact the development team#formatterURL for Wikidata ID. I'll reverse my !vote if consensus there is that this is not the right approach. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:11, 20 March 2016 (UTC)

Template:Vote delete While I don't doubt "proper procedures" were followed in creating this property, such as they were understood at the time, I think the referenced discussion and Hoo man's expertise regarding wikidata modeling should be given due weight on this. The property has not been used even once in two weeks; the example it was intended for seems not to need it any longer. If such a property really is needed in future I wouldn't be opposed to recreating, but it needs a stronger case and more discussion than was had the first time. I support deletion. ArthurPSmith (talk) 17:45, 31 March 2016 (UTC)

Template:Vote delete The discussion on Wikidata:Contact the development team has now been archived. Lydia and Hoo both seem to agree that it's not the right way to model things like that, and (as I wrote there) I agree. - Nikki (talk) 08:46, 2 April 2016 (UTC)

Template:PfD and Template:PfD

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

• Template:Ping

• What's FRBR? --- Jura 17:17, 9 January 2015 (UTC)

  Wikidata:WikiProject_Books#Bibliographic_properties. In simple words, work, translations and edition are described in different items. Snipre (talk) 07:51, 10 January 2015 (UTC)

• What is the other property that you are talking about? Visite fortuitement prolongée (talk) 18:17, 10 January 2015 (UTC)

  Template:P vs. Template:P. Snipre (talk) 00:58, 11 January 2015 (UTC)

  So you want ot merge Template:P and Template:P. Since Template:P is more specific than Template:P, and since you wrote "we don't need anymore two properties to describe language of a work [...] The original language of the work can be retrieved from the language property of the work item", then I suggest to delete Template:P instead of/and not Template:P. Visite fortuitement prolongée (talk) 20:16, 11 January 2015 (UTC)

  Visite fortuitement prolongée I am pragmatic: use of Template:P: 95129, use of Template:P: 7588. See Wikidata:Database_reports/Constraint_violations/All_properties Snipre (talk) 14:56, 12 January 2015 (UTC)

• What would happen with films in FRBR? --- Jura 17:37, 12 January 2015 (UTC)

  Same as translations for book: a new items for each translated version in order to put the name of the "voices". Snipre (talk) 17:25, 14 January 2015 (UTC)

I see there is a lot of good arguments, but the two properties can´t be merged easily. In cases where p 364 is uses as it should be, it must be deleted and secured that p 364 is added to the corresponding work item. In many (thousands) of other cases p364 is used not the way as it is intended instead of p407. So p364 is messed up much more than p 407. I find the concept of p407 is easier to understand, so I suggest to change the RFD round to delete p364 instead, no matter how often the property is used. Once it is done properly, a bot can change the number within hours.--Giftzwerg 88 (talk) 18:42, 18 January 2015 (UTC)

• I suppose that Template:P is used also for other types of entities, for example, in names. Which is not easily convertible to Template:P. --Infovarius (talk) 14:03, 20 February 2015 (UTC)
• I have used Template:P a lot on WikiNews items. Several of them had multiple languages attached. I would therefor keep it. Edoderoo (talk) 22:19, 22 March 2015 (UTC)

  Template:Ping What is the problem if we merge both properties into "language" ?Snipre (talk) 13:05, 23 March 2015 (UTC)

  Template:Ping Can you provide an example please ? And if the new property is called "language", is it still a problem ? Snipre (talk) 13:05, 23 March 2015 (UTC)

  • Template:Ping, find an example here: Template:Q. In case "language of work" will be cancelled completely, yes, then "language" would be a replacement. Edoderoo (talk) 13:44, 23 March 2015 (UTC)
    • About 60 of the 8000+ occurences are now on WikiNews articles. But I found more weird occurences, like given names with this property. Edoderoo (talk) 10:55, 24 March 2015 (UTC)

  Template:Ping How can you use a language property for a wikinews article ? As I see there is a French corresponding article so why English and not French ? Snipre (talk) 16:26, 27 March 2015 (UTC)

  Because English *and* French. I'm Dutch, so for me the English and the French go perfectly together on the same property without any issue ;-) Edoderoo (talk) 22:07, 27 March 2015 (UTC)

  A wikinews can be in language "A" about some public speech which was performed in another language "B". I suppose we can point both languages with different properties (Template:P for A, Template:P for B). --Infovarius (talk) 08:36, 2 April 2015 (UTC)

  Template:Ping You mix different concept: the language of the wikinews and the language of the object of the wikinews article. For the first language, this is redundant with the sitelink information. If you want a French article you filter the sitelinks and select the ones which are in French. The example you gave was an typical example of the problem of redundancy: the language properties were not updated according to the sitelinks. And this organization is not applied in the others items: the language property is never used to describe the language of the WPs connected to the item. Look at Template:Q: 153 sitelinks and around the same number of different languages. But no use of Template:P or Template:P. So why do we have to have another practice for wikinews articles ?

  Then about the language of the object of the article. Here we have a problem of definition: Is the item about the wikinews article or about the object of the article ? The classification of the item is clear in your example: instance of Wikinews article. So the language of the object in not part of this item. You should use Template:Q to define the language of the object of the article, and how can an election have a language property ? Here we have a confusion based on the relation "the election is in Israel", "Hebrew is speaking in Israel" so "language of election is Hebrew". Snipre (talk) 14:31, 7 April 2015 (UTC)

• Template:Ping Which "language property of the work item" are you referring to? As far as I can tell, it's possible to create an item without any language property except for Template:P unless someone uses Template:P and signifies the language. There are occasionally works that have titles in more than one language, despite the text only being in one, so going by the title language doesn't make sense to me. The way the descriptions are written, I've always used Template:P as the language of the first edition, not necessarily the current translation. To me, that's been Template:P. Hazmat2 (talk) 15:42, 27 April 2015 (UTC)

  The idea is to have one language property called "Language" and to use this property for work AND editions items. The use of the merged property "Language" can be used to retrieve all works in a defined language as well to define the language of the editions in the original language or the language of the translated editions. No need any more of a original language property for work and another property for the editions items. We can't use the language of the title because the language of the title can be different from the language of the work/edition. --Snipre (talk) 16:05, 10 May 2015 (UTC)

• Understood. Thank you, Hazmat2 (talk) 20:21, 26 May 2015 (UTC)

• Template:Support merging two properties (Template:Property and Template:Property) into one. Target name shall be "Language". -- Vlsergey (talk) 11:41, 20 May 2015 (UTC)
• Template:Ping and Template:Ping I modified a little the description text of the proposed action:
  

The proposed action is to merge Template:P and Template:P in one property "Language" which can be used for all cases where an item or a statement has to be defined according to its language. This can be for work, but for name or other kind of items.

Please provide your support or opposition to this request in order to progress to a decision. If you are not convinced better vote {{oppose}} but this wiil help at least to close the discussion. Thank you. Snipre (talk) 16:18, 26 May 2015 (UTC)

• If Template:P and Template:P will be merged, then how to handle in a case when the original text is unknown, but we know the original language? -- Sergey kudryavtsev (talk) 10:02, 27 May 2015 (UTC)

  Template:Ping Please provide an example. I don't understand the problem. Snipre (talk) 10:44, 27 May 2015 (UTC)

  The example: s:ru:Я целый день изнемогаю (Гейне/Фет) — we know the translator — Template:Q, the author — Template:Q and the original language — Template:Q, but we don't known the original text. -- Sergey kudryavtsev (talk) 11:30, 27 May 2015 (UTC)

  Template:Ping What you say about this example? -- Sergey kudryavtsev (talk) 03:55, 4 June 2015 (UTC)

  Template:Ping The rule is for translation to have a different item. So in your case you should create an item for the original text and a second one for the translation. We don't care about the original text because we use concept in WD. So in the item of the original text we use "language": german and in the second "language": russian. Snipre (talk) 08:07, 4 June 2015 (UTC)

  The way, which you recommend, is very unnatural. In fact you suggest to describe in wikidata the hypothetical, irreal things. -- Sergey kudryavtsev (talk) 10:28, 4 June 2015 (UTC)

  Does your original exist or not ? If you have proof that a translation was made (like a reference) so you can't say that the text was hypothetical or non real. In summary if you have enough sources to say that the author was Template:Q and that the original language was German to put that information (all information should normally have sources in WD) in the item of the translated text, you have enough proofs to be able to create an item for the original text. Snipre (talk) 20:29, 4 June 2015 (UTC)

  Does your original exist or not ? — we don't know this until the original will be found. The text in the books has a subttle "From Heine", but not say which exactly. The subtitle may be true or false — we don't know. E.g. this poem by Template:Q has a subttle "Изъ T. Мура." ("From T. Moore" in English). In fact this isn't a translation from Template:Q, but the original poem! Minaev put this subttle to easyly pass the censura barriers in the Russia:

  В русской переводческой практике 60-х годов случаи публикации "переводов" без оригиналов были нередкими и даже до известной стег пени оправданными: оригинальное стихотворение с вольнолюбивым содержанием легче прорывалось в печать сквозь цензурные рогатки, если оно объявлялось переводом какого-либо известного иностранного автора; именем чужеземного поэта прикрывались также первые робкие попытки начинающих литераторов, пытавшихся ускользнуть от критических упреков, всегда звучавших строже по отношению к еще безвестным в литературе новичкам. Имя Мура в этом смысле также служило порой щитом для неофитов: известны, например, стихотворения Д. Д. Минаева, выдававшиеся за переводы из Мура, но в действительности ими не являвшиеся.

  431 Таково, например, стих. Д. Д. Минаева "Просьба", в качестве перевода из Мура вошедшее в хрестоматию Н. В. Гербеля "Английские поэты в биографиях и образцах", с. 250:

  Не молись за меня!-- может быть, это грех,
  Но в мольбу я не верю, не верю судьбе!
  Помолись, моя милая, лучше за тех,
  Кто еще не измучен в борьбе...

  Оно впервые напечатано в качестве оригинального стихотворения без всякого указания на Мура в кн.: Д. Д. Минаев. На перепутьи. Новые стихотворения. СПб., 1871, с. 172. — Template:Q, Мур и русские поэты 40--50-х годов: А. Фет, И. Крешев и др.-- Отзвуки популярности Мура в русской литературе второй половины XIX века.

  The article above is written by a expert in literature, not dilettante. In this case we believe the expert (see this poem in ru-ws). -- Sergey kudryavtsev (talk) 11:43, 5 June 2015 (UTC)

  Sorry I wasn't accurate when I was asking if the original text. WD like WP don't need to have a proof of existence to create an item or an article, they just need to have a document with some authority saying that was true (or not) and then you create your item based on that source and you cite the source in the different statements.

  If you have a document X saying that text Y is a translation of text Z and that the original language was OL with the author AA and the translation was done by TT in language TL, you can create three items:

  • item about document X
    • All details about document X according to Help:Sources
  • item about text Z
    • author: AA, source: item about document X
    • language: OL, source: item about document X
  • item about text Y
    • translation of : item about text Y
    • translator: TT, source: item about document X
    • language: TL, source: item about document X

  Snipre (talk) 16:23, 7 June 2015 (UTC)

  You have a mistake: Y and Z is muddled. ;-) But this is not impotant in a case of unknown original text (s:ru:Я целый день изнемогаю (Гейне/Фет)). -- Sergey kudryavtsev (talk) 17:59, 7 June 2015 (UTC)

  Thanks. Snipre (talk) 11:40, 10 June 2015 (UTC)

• Template:Oppose There can be situations when 1 property can be not enough. I can not find convincing example, but here is another one. A film (for example, animated) can be in language A originally (Template:Property), but Template:P can provide different backgroud languages (so Template:Property can be used as qualifier for them). --Infovarius (talk) 10:21, 27 May 2015 (UTC)

  Already treated: in the data structure of WD your scenario is described by two items: one for the original movie with the main voices and then a second item for the second language with another set of voices. You can't mix now all voices for different languages in one item. The only open question is about subtitled versions. But you can perhaps show the problem using this item Template:Q. Snipre (talk) 10:35, 27 May 2015 (UTC)

• Template:Keep the both properties. Instead of deleting, we should impose the rule about Template:Property and Template:Property: either only Template:Property (for the original works) or both (for the translated/dubbed works). -- Sergey kudryavtsev (talk) 10:28, 4 June 2015 (UTC)
• Template:Vote delete Merge the two properties. Per Snipre. --Casper Tinan (talk) 11:43, 4 June 2015 (UTC)
• Template:Vote delete. Merge the two properties. Name the merged property "Language of Work". Create a new property named "Language" for names and other things that aren't creative works. Filceolaire (talk) 20:56, 18 June 2015 (UTC)
• Template:Keep both properties. It's easier to have a separate property than a property plus a qualifier for the main use case. --- Jura 17:10, 26 June 2015 (UTC)

  Template:Ping Sorry but I don't see where you find the mention of a qualifier: we don't need a qualifier because according to the general structure for works in WD you create different items for the different versions of a work. And when you need the language of the original version you use the data of the item of the work and not the items of the versions. Snipre (talk) 12:36, 1 July 2015 (UTC)

  I don't see people creating items for each synchronized version of a film. Original language is sufficient as a property for these (P364). Add additional languages with the other property if you must. It would be a horrible mess if we would create multiple items for the same film or tv series. --- Jura 12:42, 1 July 2015 (UTC)

  Template:Ping You don't see people creating items for synchronized versions because they aren't trained to do it. But now the question it to now for which purpose you want to add Template:Property in an item of a movie ? Just to say that a movie exists in a certain language ? What's about the publication or release date of the synchronized versions ? What's about the name of the voices in the translated versions ? Just think about anime movies where for each language and for each character you have a different person. "It would be a horrible mess if we would create multiple items for the same film or tv series." That's what we are doing for books and this was never a problem. Snipre (talk) 15:29, 15 July 2015 (UTC)

Template:Ping It's not as simple as training people to create multiple items for a film. The size of that task is very large, there are nowhere near enough contributors. Consider Star Wars, for example: [[4]], see how complicated it gets? If we are to have an item for each release/edition of a film, this work will have to be automated. So, the automation part needs to be solved before these properties can be merged. I would support merging after seeing a proper plan on exactly how all of this will be done. Danrok (talk) 15:29, 23 September 2015 (UTC)

• Template:Vote delete Merge the two properties. - The use of the 2 different properties is a mess while treating articles in periodicals. One Language property is enough. --Hsarrazin (talk) 12:17, 1 July 2015 (UTC)
  • Just add P364 and you are fine. --- Jura 12:42, 1 July 2015 (UTC)
• A book can be a translation in a specific language from a specific original language. If we remove the original language, then we must always have an item for the original work. We get away with one less property, but must add a whole bunch of new items for the works themselves. But then, translations should be a directed graph… The language is a property of the original work, and the translation is done from a previous work and into a new one, implying the new work should have its own language likewise the old work. Will there always be an item for the old work? If not then we need an original language. Jeblad (talk) 22:39, 29 July 2015 (UTC)
  • Template:Ping The creation of a specific item for each edition/translation is already a "rule" in WD (see help:Sources#Books) because each translation has dedicated properties which have to be distinguished from the original edition. How can you specify the Template:P, Template:P, Template:P, Template:P, Template:P, Template:P and all others identifiers which are different for each edition/translation if you mix several editions/translations into the same item ? The question is not the deletion of one property, the question is to have one system so if you want to keep original language you have to create "original place of publication", "original publisher", "original ISBN",... We have to be coherent. Try just once to provide some specific data of one edition/translation and you will understand why you need each time one item per edition/translation. Snipre (talk) 07:18, 30 July 2015 (UTC)
    • That is a help page and not a policy. Try to create items for news articles with a bunch of reprints, when you only have an approximate idea who is the first publisher. We need to be both accurate for important works and to provide something usable in the simpler cases. Jeblad (talk) 06:13, 31 July 2015 (UTC)
      • Template:Ping There are no simple cases: what is the benefit to know that an article is translated in Japanese if you have no way to find it ? And nobody asks you to create items for all editions/translation of a document, only one for the document you want to use. Who asks you to look for the data of the first publication ? Nobody. If you have a reprint, just create the item for your reprint and create an empty item for the work in order to link later all reprints. If you don't want to do that better avoid to add data: useless data stay useless even when mix with good data. The data in WD have to be read by people and machines, I really want to know how machines will understand your concept of simple cases and important works. What is an important work ? What is not ? Snipre (talk) 14:03, 31 July 2015 (UTC)
        • Take a deep breath, other people disagree with you, it will happen in life. Jeblad (talk) 14:27, 31 July 2015 (UTC)

Template:Ping Thank you to admit that your opposition is based on nothing. And by the way, help:sources is not a simple help page because it is the result of a RfC: there was a choice behind that RfC, and the community agreed about one solution. Snipre (talk) 16:49, 8 August 2015 (UTC)

• merge the two properties, with the FRBR system (which is already widely used on Wikidata and everywhere outside) it's very easy to understand (for both human and robot) to understand if the merged property should be understand as Template:P or Template:P. Cdlt, VIGNERON (talk) 21:40, 6 September 2015 (UTC)
  • I think you are confusing books with works in general. About "widely used": do you have any samples and references for films (on Wikidata and outside)? --- Jura 08:09, 10 September 2015 (UTC)
    • Why can't « other » works use FRBR ? FRBR is « Functional Requirements for Bibliographic Records » ; it's not specific to books. And even if the FRBR or a similar system isn't used for some works (which is proably not a good idea in the long run but this is completely understable), I still don't see the need for two porperties. Cdlt, VIGNERON (talk) 17:41, 12 September 2015 (UTC)
      • I'm attempting to address your argument that this is "widely used", but apparently, by not responding to it, you confirm that this isn't the case. --- Jura 15:43, 23 September 2015 (UTC)

• Template:Keep for now. Merging these two properties without having a well thought out plan on exactly how data will be collected would be a mistake. For example, creating new items for each language release of a film is a very large and complex task. It is not a simple as one might imagine, there can be dozens of releases of a single movie across differing media, i.e. theater, VHS, DVD, Blu-ray, etc. Bear in mind, in the case of Blu-ray, several languages may be encoded on to the disc. This cannot possibly be done by humans, unless we have a few thousand contributors willing to work on this. I'd suggest looking at this again in the future, when we may have more suitable automated tools available. Danrok (talk) 15:13, 23 September 2015 (UTC)
  • "we can't create items for each language" is not an argument against single property. You are not required to create multiple entries. Would one like to describe new element such as different edition -- he can create new item. From work complexity point of view it does not matter would it be new item or existing one. In addition, single property does not prevent you from using single item to describe multiple editions. -- Vlsergey (talk) 15:23, 23 September 2015 (UTC)
    • Can you explain how one should identify the original language for a film if you merge the two properties? --- Jura 15:43, 23 September 2015 (UTC)
      • So, what current entity is about? Is it about single translation or original movie? In first case you shall (but not required) to create new item and specify it as P629 value of translation. By next step you either specify language on new entity itself or as qualifier of P629 property. Also P629 can reference itself -- you won't need to create separate item, but self-referencing will be very confusing. Also one can set "unknown value" (if too lazy to create separate item) and put all "original movie" properties as qualifier of P629 property. Back to second case -- when current element is original movie and one want to describe translation. Just add "unknown value" (if too lazy to create separate item) to P747 property and describe language as qualifier. -- Vlsergey (talk) 11:10, 24 September 2015 (UTC)
        • Let's take this one as a sample: Q14955307#P407. You merge the properties and we end up with "languages: sv, de". How do we know that the original language is sv? Assuming no new items are created. --- Jura 11:37, 24 September 2015 (UTC)
          • Template:Ping assuming this entity is about movie, and not about translation, I moved (copied) "de" to edition property: Q14955307#P747. You can add additional properties here (like date of publication of de-edition or additional codes special for de-edition). Thus language of original work will be value of Q14955307#P407. This example assumes we are too lazy to create distinct entity for each translation. -- Vlsergey (talk) 11:57, 24 September 2015 (UTC)
            • Ok. I see how you'd do it, but it doesn't actually require deletion of "original language of work (P364), doesn't it? It might as well work with the existing property. It would have the benefit that we know what the original language is -- currently we don't because both sv and de are listed as language of work (Property:P407). --- Jura 12:34, 24 September 2015 (UTC)
              • Template:Ping 1. Well, nothing really requires to delete the property. It just makes things more complicated and confusing from model point of view. In this particular case 361 is not a original language, but language of the same element. In other cases it is duplication of property from "parent work" entity. 2. I kept "de" in P407 property just to make sure not to break any infoboxes. It could be deleted, leaving "sv" as single value of 407. -- Vlsergey (talk) 20:20, 24 September 2015 (UTC)
                • I'm not really sure if the original language is sv or sv+de. I picked this sample as the item used it in a way that items would use if this proposal would go through. If deletion is not required and in order to close this discussion, would you oppose the deletion proposal so we can move on? --- Jura 09:31, 25 September 2015 (UTC)
                  • 1. Well, me neither, I just checked the infobox data in svwiki. 2. Of course not. I insist that property should be deleted. When I said "nothing really requires" i just reflected your opinion that usage of my scenario doesn't require deletion of property. But this is like trying to prove that you don't need to stop littering to hire a cleaning guy. You need both: to hire a cleaning guy to cleanup the mess AND to stop creating more mess. We need to select some scenario to reduce mess with translations (incl. movie translations) AND we need to prevent such mess from arising again in future by deleting "original language" property. -- Vlsergey (talk) 14:43, 28 September 2015 (UTC)
                    • You will be needing a cleaning guy for your solution as it's not clear what people should enter in the merged "language" field. Currently it's clean! --- Jura 19:58, 29 September 2015 (UTC)
                      • It is completely clean that language field shall contain original language of entity and language of derived items should be in "language" property of separate item. Current solution with language+original language is a mess. It indulges people to put all data into single item for all languages and all translation, creating real mess from movie item. -- Vlsergey (talk) 13:51, 5 October 2015 (UTC)
                        • A single item that isn't entirely accurate shouldn't be much of an issue. Clearly your fear hasn't realized. --- Jura 17:18, 5 October 2015 (UTC)
                          • Well it is. Clearly my fear already realized. I already see items that include both original work information and translation information, thus creating mess with structure and data even for other properties (such as date of publication or voice actors list) -- Vlsergey (talk) 12:40, 6 October 2015 (UTC)

• Template:Keep for now. Regardless of whether other types of works should be modeled according to FRBR, I think it's apparent that at this point, they aren't. The redundancy from reciprocal properties is a much more manageable and reversible issue than the one that would arise from a hasty merge that disrupts the existing workflow for a category such as films. FRBR is not a panacea, and is not the sort of drag-and-drop solution it is being made out to be. Dancter (talk) 19:34, 23 September 2015 (UTC)
  • I don't see arguments regarding merging or non-merging properties. It is not FRBR requirement to merge or keep properties, it is just that FRBR model can be used as example of model where two properties are not required. You still can use single element to display information about single movie with all it's translations (if one would like to). But for sure you will need to create new element as soon as one would like to describe translation voice actors (and not mess them up in case there are 2 or more translations to single language). -- Vlsergey (talk) 11:10, 24 September 2015 (UTC)
    • What specifically are you asking for? Not requiring two properties is not the same thing as requiring one property. Redundant properties should be a relatively manageable issue, particularly reciprocal properties such as these. Disrupting the existing workflow for film category edits by removing a property without firmly establishing a consensus, guidance, and transition for a replacement protocol is more problematic. FRBR is the justification being offered for the merge, despite the fact that the model is not being used everywhere on Wikidata. Effectively imposing that model (or whatever you want to call the particular work-edition model being proposed here) to other domains is not that simple, especially with only cursory nods to implementation, and it should not be something decided in a discussion ostensibly about the deletion of Template:P). My other objections go more to Wikidata philosophy in general (deleting, merging, property discussions, qualifiers, redundancy, etc.) and are probably beyond the scope of this discussion. Dancter (talk) 19:25, 24 September 2015 (UTC)
      • I assume you have in mind "current" workflow (perhaps with multiple translations in single element) and want to have some formal discussion regarding moving from one workflow to another. But sorry, there is no such distinguished "workflow discussion pages", and property deleting discussion page is already used for such things. -- Vlsergey (talk) 20:24, 24 September 2015 (UTC)
• Template:Vote delete Let's keep the language or name scheme as simple as possible. author  TomT0m / talk page 19:13, 4 October 2015 (UTC)
• Template:Vote delete Merge the two properties. Per Snipre. Carlos Porto (talk) 00:03, 16 October 2015 (UTC)
• Template:Keep, there are books in English that are translations of French editions of Dutch books. The language of the edition is thus English; the source from which it was translated in French; but the original language of the work is Dutch. I am thinking specifically here of The Waning of the Middle Ages, where the first English editions were (badly) translated from the French; the edition more recently translated directly from the Dutch has a different title. This sort of intermediate translation happens with high regularity for ancient texts (The first English translation of Hammurabi's Code was made from the German translation of the original) and so there needs to be a way to distinguish current language, source language, and original language. Eliminating the distinction without having a plan in place to accommodate this sort of data would not be a wise move. --EncycloPetey (talk) 02:28, 27 October 2015 (UTC)

Template:Ping Thanks to mention that particular case but I think just multiplying the languages properties in an item will be a problem because for most contributors there is only one language for one edition.

For the mentioned case I think the relation between translated works should be made using Template:P and perhaps even create a different property to distinguish between "edition of" and "translation of". For example if I want to know the language of the edition used as source (this edition can be the original one or a already translated edition) I extract that information from the corresponding item. I completely not understand why we have to create special properties for language and not for author. If we need current language, source language, and original language why don't we do the same for translator, translator of the source and author of the original work ?

The logical way is to put all relevant information in the appropriate item and to link the different items in order to be able to look for the information at the correct place. Snipre (talk) 12:31, 27 October 2015 (UTC)

Template:Ping Thanks for your comments. Perhaps we can agree that a merge at this time is premature? A larger discussion is probably needed to decide how to deal with the related issues. If a suitable method can be found, then a merge might be possible, but I think a merge at this time would merely result in a loss of information. --EncycloPetey (talk) 19:53, 27 October 2015 (UTC)

• Template:Comment an easier solution for the library catalog problem might be to create a separate namespace/entity-type (sample: "E") for books. These could link back to works in the usual Q-namespace. Maybe some other thing would be better there as well. --- Jura 14:26, 27 October 2015 (UTC)

  There was this prototype for source Wiki-database some Wikidata Weekly weeks ago. But I think another namespace will actually create more problems that it would solve. author  TomT0m / talk page 14:49, 27 October 2015 (UTC)

  Wasn't that just a copy of something unrelated already running elsewhere? Obviously, it would need some coordination per namespace, but not necessarily more than is needed now on "every" item. It could also solve some of the issues with wikisource. --- Jura 15:27, 27 October 2015 (UTC)

  The simplier solution is to apply strictly the FRBR model. Using that structure we store each data in only one item and when we need to have data from other items we look for it in the other items. Snipre (talk) 15:40, 27 October 2015 (UTC)

  Maybe we could do that by simply linking to some other cat. --- Jura 15:55, 27 October 2015 (UTC)

• Template:Vote delete I've been thinking about this issue for a while. Let me give an example:

This summer I added some Spanish release dates (with Template:P) for movies, tv series, tv seasons and tv episodes. Usually I also added original network (Template:P, for TV-Movies) and title (Template:P). My method was simple: every fact comes with a qualifier Template:P => Template:Q. See some examples: Template:Q, Template:Q, Template:Q, Template:Q.

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

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

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

• Template:Keep Gangleri also aka user:I18n ^{(depending on browser)} I have seen hundreds of P407.07:46, 12 January 2016 (UTC)
  • "I have seen hundreds of P407" -- it's not a valid reason to keep, actually. -- Vlsergey (talk) 19:23, 13 January 2016 (UTC)

• Template:Keep The two properties can sometimes be a mess, but, e.g., for Template:Q it makes sense to me. The Template:P is Template:Q while it exists in a number of other languages. Splitting the item into translated versions seems to babelfuscate language links? — Finn Årup Nielsen (fnielsen) (talk) 19:45, 22 January 2016 (UTC)
  • You have 2 values for Template:P, 6 for Template:P (with missing qualifiers), 5 for Template:P (with missing qualifiers again!), 4 for Template:P, 4 for Template:P, 3 for Template:P... I would say this is a very good example of one-item-for-all-languages-mess, and that's exactly why it shall be split (and properties -- merged). -- Vlsergey (talk) 18:43, 26 January 2016 (UTC)

• Template:Keep the both properties. I like 'language of work or name', I use it with property 'named after'. I can live with 'language of work or name' (P407) as subproperty of 'original language of work' (P364), as well. --Chris.urs-o (talk) 09:01, 12 March 2016 (UTC)
  • Chris.urs-o The question is not to know if you like one property or not but to know if having only one property 'language' is a problem for your work ? Template:Unsigned

• Template:Vd Template:P in favor of Template:P, Template:Neutral on Template:P --Srittau (talk) 16:00, 16 April 2016 (UTC)
  • And a procedural note: Since this deletion request was started, Template:P was created, which changes the basis for this discussion. I would recommend to close this discussion, keeping both properties, but create two new separate deletion requests, based on the existence of the new property. --Srittau (talk) 16:03, 16 April 2016 (UTC)
• Template:Vote delete - merge these two --Lingveno (talk) 11:23, 26 May 2016 (UTC)
• Template:Ping Can you close this RfD ? Change lead to reformulate the deletion request. Snipre (talk) 00:37, 7 June 2016 (UTC)

Template:P and Template:P

• Template:P Template:Rfd links
• Template:P Template:Rfd links

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

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

  I'm not sure about other countries, but in America, that is the case for residential homes. (We have a really !@#$ed up housing situation here....) --Izno (talk) 11:52, 26 May 2016 (UTC)

Property:P1658 (number of faces)

Template:Discussion top Recently the properties number of edges and number of vertices were replaced by Template:P with qualifier Template:P. Template:P is a property of the same kind and can also be replaced by Template:P. Template:Ping ping property proposer and creator --Pasleim (talk) 12:37, 10 May 2016 (UTC)

• With Template:Q? Delete if so. --Izno (talk) 12:59, 10 May 2016 (UTC)
  • yes. Example: Template:Claim --Pasleim (talk) 13:12, 10 May 2016 (UTC)
• Is it possible to query the qualifiers of Template:P using the sparql interface? And as usual I would like to remind everyone that Wikidata is capable of handling multiple ontologies. Template:P and other, more specific properties, can happily coexist. So currently I favour Template:Keep. --Tobias1984 (talk) 20:52, 10 May 2016 (UTC)
  • We can "handle" multiple ontologies, but we should not due to a shit ton of reasons. There may be some exceptions, but this should not be one of them. --Izno (talk) 14:55, 11 May 2016 (UTC)
• Delete definitely. (A) it looks like everything that could use this property is already using Template:P with the suggested qualifier. There are a relatively small number of named three-dimensional polyhedra that this could apply to so it really doesn't seem useful to keep a custom property around for this. (B) from a mathematical standpoint, "face" is a 3-dimensional concept and I don't think we'd want to generalize this to the corresponding properties in each higher dimension for any special objects of mathematical interest, especially since the corresponding properties for edges and vertices have already been removed. On Tobias's question - yes, you can query for qualifiers via the wikidata SPARQL interface but it's a little more complicated as you need to use the full statements rather than the "truthy" ones. ArthurPSmith (talk) 18:59, 11 May 2016 (UTC)
• Template:Ping sample query to get the number of faces. --Pasleim (talk) 19:30, 11 May 2016 (UTC)

Template:Ping Thanks for sharing the query. I guess that addresses my main concerns and I can along with the deletion. --Tobias1984 (talk) 16:46, 12 May 2016 (UTC)

• • Hi guys; Template:P' or Template:P' ? Technically there is many instances of this kind of polygons. author  TomT0m / talk page 17:19, 17 May 2016 (UTC)
    • This is a class to class relation. --Izno (talk) 18:10, 17 May 2016 (UTC)
      • Oh yes right, I'm tired ... author  TomT0m / talk page 18:13, 17 May 2016 (UTC)
• Agree with delete per similar changes to the handling of vertices / edges. Deryck Chan (talk) 16:55, 20 May 2016 (UTC)

Template:PfD

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

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

Property:P1244 (phone number (URL))

Unused duplicate of Template:P--Srittau (talk) 15:07, 23 May 2016 (UTC)

• Template:Oppose. In the meantime URL with tel: can be implemented. So the announced use of that should be honored. Template:P should be deleted instead.
  --- Jura 15:15, 23 May 2016 (UTC)
  • Template:Vote delete seems like P1329 can be made to work better
    --- Jura 15:51, 24 May 2016 (UTC)
• Template:Comment For discussion see Wikidata:Project_chat#phone_number_.28URL.29_.28P1244.29_and_phone_number_.28P1329.29.
  --- Jura 15:15, 23 May 2016 (UTC)
• Template:S deletion. Template:Ping from the PC discussion. --Izno (talk) 09:16, 24 May 2016 (UTC)
• Template:Vote delete As per project chat discussion. - Nikki (talk) 09:35, 24 May 2016 (UTC)
• Speedy keep until the linked discussion is resolved (leaning delete in the long term). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:26, 27 May 2016 (UTC)
  • Well, that discussion was basically over and showed a clear consensus, in my opinion, therefore the deletion request. --Srittau (talk) 16:31, 29 May 2016 (UTC)

Template:PfD

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

• How would using an URL fix the malformed inputs? There is nothing preventing you from entering URLs that don't conform to the format prescribed by tel:. --Srittau (talk) 15:27, 23 May 2016 (UTC)

  Also Template:O, Template:P has clearly won the popularity contest and is the better property, since representing phone numbers as URLs adds an unnecessary level of abstraction. --Srittau (talk) 15:29, 23 May 2016 (UTC)

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

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

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

    • Good point. Seems like anything like [[5]] would work. Template:Keep. Seems we have to find a different way.
      --- Jura 15:50, 24 May 2016 (UTC)
      • Do you have an actual response or are you simply being disruptive? --Izno (talk) 16:36, 24 May 2016 (UTC)
• Template:O deletion. Template:Ping from the PC discussion. --Izno (talk) 09:16, 24 May 2016 (UTC)
• Template:Keep As per project chat discussion. - Nikki (talk) 09:36, 24 May 2016 (UTC)
• What is (an example of) a malformed Template:P? Do they not work with tel:$1? — Finn Årup Nielsen (fnielsen) (talk) 05:48, 27 May 2016 (UTC)
  • See the property constraint report (or its history). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:30, 27 May 2016 (UTC)
• Speedy keep until the linked discussion is resolved (leaning keep in the long term, too). It is disruptive to make such a nomination while the property is under active discussion on 'Project Chat', and doubly so when the inverse property is already nominated (above). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:30, 27 May 2016 (UTC)

Template:PfD

Template:Rfd links Template:Discussion top Superseded by more generic Template:P. All strings in Template:P are valid in Template:P when preceded by "SE".--Lymantria (talk) 08:57, 26 May 2016 (UTC)

Template:Support --Srittau (talk) 06:59, 31 May 2016 (UTC)

Template:Support - Once id's have been migrated and any templats which use the property are updated. Template:Ping. /André Costa (WMSE) (talk) 14:23, 31 May 2016 (UTC)

Template:Support Sure. /ℇsquilo 16:06, 31 May 2016 (UTC)

Template:S Visst, kör på! -- Innocent bystander (talk) 18:14, 31 May 2016 (UTC)

After additional information at User talk:André Costa (WMSE)#EU Surface Water Body Code (P2856) I withdraw this request, since other than I thought Template:P cannot be superseded entirely by Template:P. Lymantria (talk) 05:40, 3 June 2016 (UTC) Template:Discussion bottom

Template:PfD

Some test that seems to have been created out of process by/for conference participants.--
--- Jura 09:33, 26 May 2016 (UTC)

Link to the discussion when it was created: Property_proposal/Creative_work#cites

Template:Keep Not a test. Yes to created at conference. We have strong agreement at WikiCite 2016 (https://meta.wikimedia.org/wiki/WikiCite_2016). --Tobias1984 (talk) 10:00, 26 May 2016 (UTC)

Template:Comment Yes, it is Wikicite 2016 participants that suggested (me), supported and boldly created it. Although one could be afraid of the large amount of data that could potentially be added to Wikidata, to me the 'cites' seems a well-defined property as compared to a possible "mentions" property. It would be quite useful in scientometrics of Wikidata item and in generating biographical lists (for instance). — Finn Årup Nielsen (fnielsen) (talk) 10:08, 26 May 2016 (UTC)

Template:Comment There was no opportunity given for almost everyone to comment on the proposal, to express any concerns or suggest alternatives so creation was definitely out of process. I'm not sure whether I support deletion or not, but I do object very strongly to the method of creation. Thryduulf (talk: local | en.wp | en.wikt) 10:12, 26 May 2016 (UTC)

I strongly oppose to the absence of a property creation process @Wikidata. Whereas it is well possible that this property might gain sufficient support, I vote for Template:Vote delete at this moment. Once it has passed a proper discussion at the property proposal pages, with the usual waiting time of at least a week and sufficient support, it may be recreated. We should not slip into anarchy. Lymantria (talk) 10:59, 26 May 2016 (UTC)

Template:Keep as I would Template:Support the origional proposal. ·addshore· ^{talk to me!} 11:11, 26 May 2016 (UTC)

Template:Keep I understand and agree with the points about sticking to progress: decisions should not be made offline. That said, it sounds equally ridiculous to delete the property now, just to make a point. I rather see a set of more detailed citation typing properties, like those in the Citation Typing Ontology, but welcome this predicate nevertheless. Citations are a key property in tracking provenance of knowledge, and 'cites' is just how the world works. It is not just WikiCite 2016 that had a strong agreement, but it's the whole world that agrees on this. Egon Willighagen (talk) 11:23, 26 May 2016 (UTC)

We could just as easily use the inverse ("is cited by"). The "whole world" has yet to express an opinion about which method we should use. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:59, 26 May 2016 (UTC)

Template:Comment Andy, the point about an inverse property is a good one. What's the general Wikidata policy there? I normally see the active variants, though. I am not proposing the "whole world" comments (I hope not, wouldn't have the time to read it all); I was referring to what the whole world is currently doing. We cite and we tell people what we cited. Some do this better than others, true, but giving attribution seems to be a world-wide habit. Or do you disagree? Egon Willighagen (talk) 13:24, 26 May 2016 (UTC)

Template:Replyto there is no standard policy for inverses - in some cases the "active" property is used (e.g. Template:P), in some the "passive" (e.g. Template:P) and in others we have both (e.g. Template:P and Template:P), it all depends on what the significant relationship is in the context where it is intended to be used. For citations, there are arguments to be made both ways about whether the active or passive is the more important, given that the cites used are an important part of a work but being cited by another work is what gives significance. That this was not considered at all during the extraordinarily brief discussion period is why it sets a very dangerous precedent. Thryduulf (talk: local | en.wp | en.wikt) 09:17, 27 May 2016 (UTC)

Template:Replyto Ah, thanks for the examples and info! It seems to me that everyone agrees that a clear procedural mistake was made. That just happens in enthusiasm. Deleting something just to set an example, sets an equally dangerous precedent. I was not at nor involved in WikiCite. Egon Willighagen (talk) 10:04, 27 May 2016 (UTC)

Nobody suggests "deleting something just to set an example". Deletion will allow time for a proper, open, discussion of what kind of property is needed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:39, 27 May 2016 (UTC)

The policy is that we discuss property proposals for seven days before we create them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:29, 27 May 2016 (UTC)

Template:Vote delete per Lymantria. Hint to the above: When you have multiple property creators and multiple persons familiar with the creation process telling you it was created too quickly... it was probably created too quickly. Template:Q. --Izno (talk) 11:50, 26 May 2016 (UTC)

Speedy delete and recreate if and only if there is consensus after due discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:59, 26 May 2016 (UTC)

Template:Comment Yesterday, there were some discussion at the Wikicite 2016 workshop about property creation in connection with bibliography and citation. I felt that participants were somewhat disappointed because any property suggestions would not become a property for the use in the workshop due to Wikidata bureaucracy. I suggested the property this morning by myself. And while I did expect support for it, I did not expect it to be created today and indeed laughed when Tobias1984 said he could just create it and would take any critique afterwards (if I remember correctly). Tobias1984 step was bold and in my view fine. It is a good property and immediately needed by a number of people interested in bibliographic information in Wikidata. In the discussion of the property I think we should focus on its merits rather than any Wikidata politics. If I should be political then I would say that it is usually a good idea to have a period with discussion where property merits can be discussed. I have a few times suggested properties and sometimes there had good inputs. On the other hand, I would be open to quick creations, e.g., in connections with events. In such cases property users must be prepared to have the property deleted if its merits are not there. I think it is silly to delete the property just on a background of politics. — Finn Årup Nielsen (fnielsen) (talk) 12:15, 26 May 2016 (UTC)

Template:Keep Process is important, but this property would clearly survive the proposal process and be recreated, so not really helpful to delete it. Always be bold if it improves the project! --Magnus Manske (talk) 12:36, 26 May 2016 (UTC)

Template:Keep while I agree the usual wikidata process was skipped here (especially given the recent RFC debate that firmed up that process) I don't see any point in deleting this now as I would have strongly supported creation of this property if it had been proposed the regular way. Every rule can have exceptions, we need to be reasonable. But if people start making a habit of this sort of thing I would be worried. ArthurPSmith (talk) 14:53, 26 May 2016 (UTC)

The problem with this rationale is that we have some very similarly "mass-supported" proposed properties that were all supported inside small time scale by a Template:Q group. It's an obnoxious practice. Just because some of the users in this case were from Wikidata and not a foreign wiki does not make it okay. --Izno (talk) 16:56, 26 May 2016 (UTC)

Do we trust our property creators to be watchful for canvassing etc problems? There seem to be several regular users not associated with the conference who commented on the proposal. In any case, the issue of whether somebody acted inappropriately is quite a separate thing from whether the property is worth keeping or deleting. It has already been used a dozen or so times, and seems pretty useful to me; deleting it would have a negative impact and I just don't see the purpose. If you want to send a message to the property creator here, that probably belongs on the admin noticeboard as a complaint. ArthurPSmith (talk) 18:03, 26 May 2016 (UTC)

Template:Comment does anyone who wants to delete this property actually have a reason for wanting to delete it, other than "process"? To me it looks like the only counter-argument to this property is "I wasn't consulted". And no, I'm not at the WikiCite conference. Wittylama (talk)

It's not "I wasn't consulted" but "we weren't consulted". The entire western hemisphere was asleep when the property was proposed and probably 97% of those people were still asleep when the property was approved, and the remaining 3% were probably in the shower. That's frankly ridiculous. If WikiCite thought they needed this property, or the users needed it, they either a) should have proposed it prior to the start of WikiCite, where they clearly would have received mass support or b) should have at least waited a day--after which they likely would have received mass support. One day is not hard to ask for in a decent property proposal. It's crap like this why we even have property creators and a proposal process in the first place, and I'm half-tempted to take APS's offer up regarding leaving a comment at WD:AN regarding Tobias's fit for being a property creator due to his decision making here. --Izno (talk) 20:25, 26 May 2016 (UTC)

Template:Reply to This is an unfair ad hominem you are making. Indeed I do not intend to give any reaction apart from the poor and disruptive process that has been chosen to create this property. Generally, there may be many issues with a property proposal, not only about its content, but also about the applicability of already existing properties or the datatype to be used. Therefore a reviewing time is needed. With this property I don't see many issues, but it is not only for that I care for a careful property creation process. If we forget the process for one property "because it is fairly clear that the world wants this", why would we apply it to others (most proposers will think their proposal is a good one)? That is the disruptive part of the creation part of this property. So the process, or joke of a process, that led to this property creation could be taken as arrogant and as a way of destroying procedures here. And evenly important: to users who patiently wait for weeks, months or sometimes even years, before a decision on their proposals is taken, it is truly offensive. And now you are hinting that the point would be that we would just feel passed by (rightfully so, by the way), like a bunch of jealous bureaucrats? Lymantria (talk) 06:59, 27 May 2016 (UTC)

Yes; per previous replies to your question, my objection is not "I have not been consulted" but that "we have not yet decided what is the bast approach". Please AGF. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:29, 27 May 2016 (UTC)

Template:Keep While I agree that property creation requires a careful process to avoid duplication or inappropriate classification, here we have a clear cut case: cites is not only useful but has already a long backstory as an acknowledged and delimited category in bibliometry. Getting back to the old bold wiki way seems the most appropriate thing to me at this stage Alexander Doria (talk) 22:23, 26 May 2016 (UTC) who wasn't either at wikicite

Template:Keep The "cites" property is useful and the definition looks good to me. (Any complaints about the process should IMO be discussed somewhere else.) --Zuphilip (talk) 07:18, 27 May 2016 (UTC)

Template:Keep I understand that people can be mad for not being consulted but as others I don't see substantial oppose to the property. I'm not a fan of process per se, I think that there was enough consensus and need for being bold and create something that added value to Wikidata. Also, we had the chance to work together and in person about the property, and that is a chance you really don't want to miss. Please presume good faith, this was an exceptional case. Aubrey (talk) 09:06, 27 May 2016 (UTC)

Template:Reply to But as is becoming clear above you did not consider all the aspects of the property (e.g. whether the inverse should be used instead) so while you seem to have been very lucky here not to have created a mess it is wholly inappropriate to have to rely on luck. I understand the frustration the slow process causes - I have a few proposals that have been open several months, and I'm not the only one in that position - but the process is there for a reason and I do not agree that people being in the same room is a valid reason to ignore it. I know this was done in good faith, but a wrong decision made in good faith is still a wrong decision. Thryduulf (talk: local | en.wp | en.wikt) 09:24, 27 May 2016 (UTC)

Template:Ping It's perfectly right to have doubts about the property. But cites is more constrained than is cited by: how many papers cites Albert Einstein's most famous article? Nobody really knows. And that number is changing. On the other end, the papers it cites are a limited, sure number. Also, schema.org uses citation too (as A cites B). Aubrey (talk) 09:58, 27 May 2016 (UTC)

Template:Replyto I'm not arguing for or agaTinst either cites or cited by (and this wouldn't be the place to do it if I was), simply that it should have been discussed before creation and time allowed for people who were independent of the setting where a possible need was identified to bring outside perspectives so that things like this do not get overlooked. Thryduulf (talk: local | en.wp | en.wikt) 11:01, 27 May 2016 (UTC)

Somehow I doubt that a private conference unrelated to Wikimedia is really a good sample for "work together and in person".
--- Jura 09:28, 27 May 2016 (UTC)

This is definitely NOT a "private conversation unrelated to Wikimedia". If you want my Wikimedia resumé I'm happy to provide it, and all of the others people involved. Also, the event was organized by Wikimedia Foundation and Wikimedia Deutschland, among others. Aubrey (talk) 09:50, 27 May 2016 (UTC)

Can we have statements from WMF and WMDE about this? I read that it wasn't public, but open to invited people only. That seems really uncommon.
--- Jura 10:11, 27 May 2016 (UTC)

As noted above, my objection is not "I have not been consulted" but that "we have not yet decided what is the bast approach". And I am not "mad". Please AGF, and avoid such pejorative language. It's also hard to "assume good faith" in the face of a statement like "he could just create it and would take any critique afterwards". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:29, 27 May 2016 (UTC)

Template:Vote keep! -- Innocent bystander (talk) 09:28, 27 May 2016 (UTC)

Template:Replyto Why do you think it should be kept? Thryduulf (talk: local | en.wp | en.wikt) 11:01, 27 May 2016 (UTC)

RE:Thryduulf: I added some comments to my vote before, but it disappeared after several edit conflicts. I cannot see any real purpose in deleting something and recreate it 168 hours later, just because of some mistakes when it was created. That is not Common Sense! -- Innocent bystander (talk) 11:46, 27 May 2016 (UTC)

Thank you. Thryduulf (talk: local | en.wp | en.wikt) 12:11, 27 May 2016 (UTC)

Again: No one is proposing "deleting something... just because of some mistakes when it was created". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:21, 27 May 2016 (UTC)

• Template:Comment I have started an RfC about whether we should have formal minimum time limits for property proposal discussions going forward and/or whether property creators should be independent of events/discussions that resulted in the proposal. You are invited to comment on this at Wikidata:Requests for comment/Standards for property proposal discussions, but note that while the RFC is inspired by this property creation it is not about this property and any outcome will not be retrospective. Thryduulf (talk: local | en.wp | en.wikt) 12:11, 27 May 2016 (UTC)
• Template:Comment Just so we can close this discussion I will add this comment. I am sorry that we had to rush this, but it was done out of poor enthusiasm to enrich Wikidata with something, that a whole conference-room full of people wanted to do. In my opinion that is the same sample size of users giving input that is otherwise gathered in a month of a normal property proposal discussions. In think we should maintain this flexibility in the future, as it cleary does not do any harm to Wikidata, or other queries (I made sure of the first two), or burdens anyone with work (I actually didn't think that there would not be a speedy deletion discussion plus one RfC: Wikidata:Requests for comment/Standards for property proposal discussions). Having a standard workflow is an excellent idea, but having flexibility for meetings and conferences, with a large enough sample size of the community, has its benefits too. --Tobias1984 (talk) 13:44, 27 May 2016 (UTC)
  • In this case I don't think significant harm has come to Wikidata, but the potential for it do so in slightly different circumstances is clear to me. For example, look at some of the Wikivoyage related proposals at Wikidata:Property proposal/Sister projects - if there were a conference room full of enthusiastic Wikivoyage contributors we could easily end up with a messy unstructured mess to sort out later. The volume of input is there, and that's good, but there also needs to be a diversity of input - when everyone is approaching an issue from the same angle it is not uncommon to miss things that are obvious from another approach. Even if the result isn't directly wrong in isolation, it could be duplicating something from a parallel field or be created with specificity rather than being slightly more generalised. Thryduulf (talk: local | en.wp | en.wikt) 14:23, 27 May 2016 (UTC)
  • Template:Reply to I agree with Thryduulf. I had hoped you would see that this way of property creation process is not the way it should be. In stead you confront us with a comment that we have to be flexible. Sort of "get used to it". What are the boundaries of flexibility? I am far from happy with this. Lymantria (talk) 15:19, 27 May 2016 (UTC)
  • No. Firstly, you - as the one who created this property out-of-process- are the last person who should be trying to have discussion here closed. And a self-selected group of people, no mater how capable, well-meaning, numerous or enthusiastic, does not obviate the need for an open discussion in which anyone interested may comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:21, 27 May 2016 (UTC)
  • Template:Ping A "conference room full of people" is not a good reason to ignore our policy, which mandates a discussion of at least a week. Especially considering that the group dynamics of a large gathering such as this are not really suited for a well-balanced decision. I'd like to see a statement from you that in the future you will honor Wikidata's policies for property creation. --Srittau (talk) 13:26, 29 May 2016 (UTC)

• Template:Ping Having the property creator rights also means that the community needs to trust me to make good decisions. The discussion was long enough that I could get a good idea if the property would be a good fit. I also argued at the conference against creating the inverse property. I wouldn't create a controversial property as quickly as this one, no matter how many people would argue for it. I also trust that the other property creators make equally good decisions. Finally I want to say that I remember quite a few properties that were fast-tracked to creation and although certainly a sporadic mistake was made we are overall making very good decisions. --Tobias1984 (talk) 18:30, 30 May 2016 (UTC)

Template:Keep I see a lot of bureacratic reasoning here (and indeed the creation was badly done) but no substantial argument against the usefulness of the property itself. As for the need of discussion, no need to delete the property for that ; I have some question myself but I'll simply use Property talk:P2860. Cdlt, VIGNERON (talk) 15:45, 27 May 2016 (UTC)

Lock. I don't think this is technically enforceable (and there should be no need for it to be), but it is what needs to happen here. The property needs to be locked from use until all the issues are worked out regarding the scope, definition, constraints, etc. (which should have happened before creation). Once there is consensus on that the property can be unlocked and adjusted as required, or deleted and created in a new form if it cannot be amended. Thryduulf (talk: local | en.wp | en.wikt) 20:04, 27 May 2016 (UTC)

Issues, Thryduulf? I think the scope is clear and the property is well defined. Good constraints are only a matter of time. --Succu (talk) 20:33, 27 May 2016 (UTC)

See comments in this discussion by Andy Mabbett for example. Thryduulf (talk: local | en.wp | en.wikt) 20:37, 27 May 2016 (UTC)

There are none, Thryduulf. --Succu (talk) 20:46, 27 May 2016 (UTC)

Look again. Andy (pigsonthewing) has commented several times in this discussion, raising points that should have be considered prior to creation (e.g. whether the inverse would be better), and other issues have been raised on the property talk page. It may be that no changes need to be made, but we cannot know that until they have been discussed. Thryduulf (talk: local | en.wp | en.wikt) 22:09, 27 May 2016 (UTC)

There is the question (not an issue) about the inverse property, but I don't read any argument that the inverse property is preferred by anybody. --Zuphilip (talk) 15:43, 28 May 2016 (UTC)

I don't know if anybody actually does prefer the inverse or not, but it is being discussed by several people which indicates again that the property was prematurely created, and it is also not the only issue raised. Together they tell me the property needs more discussion before use. Deleting it only to potentially recreate it would be pointless (and that is not what I am arguing for) I'm arguing for the discussion that should have happened before creation to happen before widespread use so that any changes brought about by that discussion don't leave a mess. Thryduulf (talk: local | en.wp | en.wikt) 16:40, 28 May 2016 (UTC)

• Template:Keep; this may have been created out of process but it seems to be being used productively, and I don't think removing it would be a benefit to anyone. Andrew Gray (talk) 22:49, 27 May 2016 (UTC)
• Template:Comment As property suggestor I would like to clarify a few things, particularly wrt. Wikidata:Requests for comment/Standards for property proposal discussions. While I, Tobias and others participated in the WikiCite event that was sort-of invitation only, the property was not suggested by me as an event participant or as a process in the event. The second day of the event, I woke up early and created the suggestion in my hotel room by myself. During the morning session with everyone the property suggestion must have been mentioned, at least I recall that Tobias said something like that he could just create it (and the rest of us laughed). We split in rooms and in the room, where I were in, people began to write support for it. At one point we discovered that Tobias, who must have been sitting in another room, boldly created (to my surprise) the property. In reference to the scope, I would say that the scientific citation is quite well-defined in scope and clearly identifiable, - in scientific articles and in books. In patent too. In legal texts I am less sure. Google Scholar, Microsoft and Thomson-Reuter have services for such citations. But what about news articles? If a news article cites an oral statement of Obama should we then use the P2860-property on the Wikidata item for the news article with the value as Obama? Such a discussion would be relevant on the property discussion page. I do not think it is a show-stopper and a cause for deletion. Initially, the obvious use that came to my mind was the scholarly citation as we see in Google Scholar. In regard to the inverse property "is cited by", I would not be in favour of it. Some articles, such as "An algorithm for the machine calculation of complex Fourier series", have tens of thousands of ingoing citations, while for 'cites', articles would typically have tens to hundreds of outgoing citations. My yet only serious problem with 'cites' is the potential magnitude of the use. We have tens of millions of scientific documents, and probably many patents potentially each making hundreds of citations. If Wikidata/Wikibase developers and devops, such as Template:Ping, say we are crazy and the property would cause unnecessary burden on the system, or if Wikidata editors feel that too many citations would be unmanageable, then we would need to consider axing the property. Another potential problem could be copyright issue with the references (I do not believe there is). — Finn Årup Nielsen (fnielsen) (talk) 11:59, 28 May 2016 (UTC)
• Template:Keep Process is absolutely not a reason to penalize a decision on this or any other Wikimedia sites, ever. Being antagonistic towards other users for the sake of being antagonistic completely undermines the model upon which our content is built.--Anders Feder (talk) 21:45, 28 May 2016 (UTC)
  • Process is a a reason to delete something when the incorrect or lack of process has damaged something or is causing problems. It hasn't and apparently isn't on this occasion, but your "absolutely not a reason...ever" is incorrect. Also, I am not aware that anybody here is being deliberately antagonistic towards other users - for the sake of being antagonistic or otherwise. There are people who are trying to explain why the speedy creation was wrong, why speedy creation is wrong in general terms, and what issues exist with the current property that could and should have been sorted prior to creation. Please assume good faith. Thryduulf (talk: local | en.wp | en.wikt) 23:23, 28 May 2016 (UTC)
    • No, process is not a reason to penalize something in that case either - if something has damaged something or is causing problems, then that is a reason to rectify it, not process. Ever. If you can point to damage or problems from this property, whether now or in the future, I would be interested to see it. As for "assuming good faith"... please try practicing what you preach first.--Anders Feder (talk) 01:34, 29 May 2016 (UTC)
      • Please point to where I have not assumed good faith. I very strongly disagree that the way the property was created was acceptable (for reasons given multiple times), but it was clearly created in good faith. I am not aware that this property has caused or is causing damage, but there are potential issues with it explained by multiple people in multiple place that should be addressed before it gets very widespread use. These problems do not in my view necessitate deletion, at least at this time, but until they are fully resolved I am not going to speak in absolutes. As for process, I think we will just have to agree to disagree if you are unable to imagine how, in different circumstances to what happened here, not following process can be a damaging thing in and of itself. Even this creation has the potential to weaken the property proposal process if people see that not giving time for a full independent review here didn't lead to major problems they may, with similar enthusiasm, create something prematurely that does. Thryduulf (talk: local | en.wp | en.wikt) 09:06, 29 May 2016 (UTC)
        • Dear Thryduulf, you just said that the property was clearly created in good faith. I understand your point that process is important, but (for me, at least) it's not everything. Wiki principles as Presume good faith and Be bold are actually social practices that try to emphasize the role of people, community, social norms over bureaucracy. We have here kind of overwhelming support for the property, I'd like us to stop discussing here and talk about constraints and issues with the property: the inverse property has been addressed, and constraints can be better defined not here but in the property talk. Can we proceed there? Aubrey (talk) 10:02, 29 May 2016 (UTC)
          • I am not advocating for deletion, merely holding off using the property until all things that need discussing about it have been discussed and agreed. Where that discussion happens is up to people discussing it, not me (but I agree that this is not the best venue for that). It is also not up to me whether this discussion is closed or not - I'm not an administrator here and even if I was I have contributed to it far too much to be a neutral closer. While the discussion does remain open though I will continue to (try to) correct any misstatements or misunderstandings relevant to the discussion that I see. Thryduulf (talk: local | en.wp | en.wikt) 10:38, 29 May 2016 (UTC)
        • You have not assumed good faith in assuming instead that the creator of the property has reneged on their responsibility to competently weigh the merits of a proposal before creating it just because they haven't sat around and let the proposal linger for some unwritten and unspoken magic period of time; nor have you done so in assuming that those who reviewed it were not "independent", just because they were at a conference together–as if daring to collaborate productively in person on something implies some sort of conspiracy. If you have evidence of any of those things then that would be something else–but all we seem to get are vague allusions to some unspecified thing about it not being "fully resolved" that is preventing you from "speaking in absolutes".--Anders Feder (talk) 12:41, 29 May 2016 (UTC)
          • I'm sure the creator weighed the merits of the proposal as it stood at the time he created it, and they clearly believed they were improving Wikidata by creating it at that point. Noting that aspects of the proposal had been overlooked in the discussion at the time it was closed is not assuming bad faith on anyone, nor is disagreeing that speedy creation was better than waiting. The policies and guidelines around property creation are not "some unwritten and unspoken magic period of time" they are publicly written down at pages that have been linked several times already, and which property creators need to know about before they are granted the ability to create properties. I'm not sure where you get the idea that I'm making vague allusions to things not being fully resolved - take a look at the comments on this page and on the property talk page to see that there are aspects of this property that are still being discussed. I'm even more flabbergasted by the accusation that I'm describing anything as a conspiracy - it is not and was not a conspiracy and I have never said or implied anything to the contrary. I can see how some other people's comments may be interpreted that way but I am no more responsible for them than you are. Collaborating in person is good, but not when it is exclusionary (intentionally or otherwise) as has been more eloquently expressed by Innocent bystander below than I am able. Thryduulf (talk: local | en.wp | en.wikt) 15:36, 29 May 2016 (UTC)
• Template:Keep I strongly oppose the way this property was created. Nevertheless, considering the fact that this property would most likely be created later (I would Template:S a proposal), if we would delete it now, deleting it would be unnecessarily disruptive and not help the project in any way. --Srittau (talk) 13:32, 29 May 2016 (UTC)

• Template:Comment I would like to address also the issue of the non public conference. I'm not one of the organizers, but as I understand the conference has been organized in very few months, with support of WMDE, WMF and external organizations, and given the limited budget there a venue with limited seats available was booked. So the non public thing was mostly a constraint given by lack of funds. It is important, I think, to state this because many people here think about the conference as a private event, giving the creation of the proposal a sort of conspiracy aura. I can assure you it was not like that. (for example, next Wikimania will be in a remote town in Italy, and will probably be less participated than other Wikimanias: will that qualify as non public? It's safe to assume that some properties will/would likely be created there too). Aubrey (talk) 14:05, 29 May 2016 (UTC)

  Well, Aubrey, Wikidata is a Wiki, not a conference! Anything outside of the wiki is "non-public" here, no matter how many attended and how it was announced. I do not even consider Wikidata related IRC and email-lists "public" here, even if anybody can read them. Of course, you can discuss Wikidata and its content on any conference/wikimania or even with your boy/girlfriend in you kitchen if you like. But, except for some extra-sensitive issues (like OS), we take all important decisions as a community in the Wiki. But my opinion here is not that you took some shortcuts here is the largest problem. The largest problem is all the noise it caused. How we could avoid that next time somebody takes such a shortcut, I do not know. To ban every possibility to take shortcuts looks like a bad idea. It would be against Wikidata:Common sense, which also is a policy, like Wikidata:Property creators is. Therefor I want the "should" in "The period before a property can be created should be no less than one week" to stay where it is. Í have just read a StarTrek-novell. Kirk there tells us that "It is easier to ask for forgiveness than to ask for permission". (He went back to 1985 to rescue some shipwrecked aliens in New York without asking his boss first.) -- Innocent bystander (talk) 14:52, 29 May 2016 (UTC)

  It seems that we agree :-) Leaving some room for shortcuts and "common sense" it's very important, IMHO, and, also IMHO, this was a case where the benefit of having a property created asap allowed people to tinker, experiment and do stuff. I hope that in the future other people will have the same opportunity. Aubrey (talk) 15:01, 29 May 2016 (UTC)

  There are plenty of existing properties that could be used for people to "tinker" and "do stuff", and sandboxes for people to experiment in, without the need to shortcut the discussion process. I'm baffled by the apparent lack of realisation that the lack of significant problems to the database caused by this speedy creation was not down to "common sense" but to a large helping of luck. To me the "common sense" aspect of the property proposal process - i.e. getting a diversity of input on a proposal before creating it - is the very thing that was skipped in this case. Thryduulf (talk: local | en.wp | en.wikt) 15:24, 29 May 2016 (UTC)

  Perhaps you have some sort of technical insight on this issue that I am missing: what exactly are the "significant problems to the database" you envision could have arised within the 4 minutes from the property was created[6] until this PfD was filed[7] or some immediate future thereof?--Anders Feder (talk) 15:46, 29 May 2016 (UTC)

  Template:Ec You misunderstand. I am not saying there are potential significant problems with this property, I'm saying that speedy creation of properties without full discussion have the potential to cause significant problems (c.f. my Wikivoyage example above) such as poorly structured data, duplication, bad definitions, etc, etc. Thryduulf (talk: local | en.wp | en.wikt) 16:28, 29 May 2016 (UTC)

  No, I don't misunderstand. I'll address your Wikivoyage example specifically then: What would the worst case scenario be if one of those properties had been created in the same way as the one under discussion here? And particularly: How long would it realistically take for that worst case scenario to play out?--Anders Feder (talk) 17:09, 29 May 2016 (UTC)

  The worse case scenario would I think be a property created that is unclear in it's scope, definition and constraints and allows the addition of unstructured data. The direct effect of this would be a mess that needs to be cleaned up (volunteer time and effort - even more so if structured data has been migrated to this unstructured format), discouraged participants, and more volunteer time and effort to add in structured fashion what was added haphazardly. How long this would take to play out isn't the right question - the problem is the time and effort required to fix the issues caused. This would be a function of the number of edits made (directly using the property and any associated edits) rather than the length of time since creation. In a worst case scenario the effort would increase exponentially with use (e.g. taking multiple edits to undo 1 action). Thryduulf (talk: local | en.wp | en.wikt) 23:30, 30 May 2016 (UTC)

  How long it would take to play out is absolutely the right question, regardless of whether it fits your narrative or not - if the elusive "significant harm" you allude to isn't something that happens within the first 4 minutes after the property being created, then this PfD isn't based on evidence, but on mere speculation, because 4 minutes was all it was allowed to exist for before someone felt it their duty to assert their power to bog it down in bureaucratic drama. As for the unsubstantiated speculation itself, that the mere creation of a property would lead to the "direct effect" of a "mess of unstructured data": what nonsense. Data doesn't magically appear in the instant a property is created. Human editors create it, and as a rule it takes many weeks or months before it amounts to anything that could tangentially be construed as "significant problems" - far more time than would be required to intercede to stop it. Your bogeyman of "significant harm" is a complete fabrication.--Anders Feder (talk) 13:06, 31 May 2016 (UTC)

  Is this why my comment at the RFC has gone completely ignored without even a cursory rebuttal? Could you explain to me or point me to a page that would show how experimentation would work for this? It still seems to me that the discussions in this thread indicates that there isn't an alternative option to tinker on properties in any practical sense. Dancter (talk) 20:32, 30 May 2016 (UTC)

  Template:Replyto If that question is for me I don't understand what is being asked. Please can you try rephrasing. Thryduulf (talk: local | en.wp | en.wikt) 23:30, 30 May 2016 (UTC)

  So, in the future, if my common sense tells me that I need a property, I should just create it, because it's all about common sense? I am certain, you misinterpret Wikidata:Common sense majorly. It says "If another policy or guideline prevents a useful contribution to Wikidata, ..." This was not the case here. --Srittau (talk) 16:23, 29 May 2016 (UTC)

  What "your" common sense tells you is irrelevant to Wikidata. If you don't know what common sense is, and/or feel an urge to use it as an excuse to disrupt the project to illustrate a point, then don't be a Wikidata editor – simple.--Anders Feder (talk) 17:12, 29 May 2016 (UTC)

  Template:Q. Common sense is not creating a property without consultation of people outside your own Template:Q (in this case participants of a conference). --Srittau (talk) 17:27, 29 May 2016 (UTC)

  That isn't common sense - that's just dumping on others for the sake of getting attention.--Anders Feder (talk) 17:37, 29 May 2016 (UTC)

  Then it seems we have different views on common sense - another reason to follow policy and not just do what you think is right. --Srittau (talk) 18:17, 29 May 2016 (UTC)

  That's a non sequitur. The fact that we have different views on common sense doesn't imply that they are equally right.--Anders Feder (talk) 18:22, 29 May 2016 (UTC)

  Template:EcCommon sense is a poor support for the creation of this property within only a few hours from it was proposed, that much I agree. But it is not worse than the users involved can be forgiven. Deleting this property now would be directly against Common sense in my opinion. And adding "must" to this policy is in my opinion also against Common sense. The exceptions Thryduulf mentions in the RFC to create supplementary properties that gain support within another property-discussion looks like a good example when a "shortcut" in this process is valid. -- Innocent bystander (talk) 18:28, 29 May 2016 (UTC)

Template:Keep per Magnus Manske . Ainali (talk) 07:46, 1 June 2016 (UTC)

Property:P2890

Template:Discussion top Template:Rfd links Created as wrong datatype. Correct property is Template:P. --Izno (talk) 17:32, 6 June 2016 (UTC) Template:Discussion bottom

Property:P999

Unused, no proposal discussion, created by banned user
--- Jura 09:52, 7 June 2016 (UTC)

• Template:Keep. The use seems clear and it's been around long enough to need to be deleted due to something silly like lack of creation data. That it was created by a banned user is mostly irrelevant. --Izno (talk) 11:44, 7 June 2016 (UTC)
• Template:Keep seems to be very far from unused as of right now. Is there a better way than proposing something for deletion to encourage use I wonder? ArthurPSmith (talk) 13:14, 7 June 2016 (UTC)
  • It seems. Nikki found the proposal discussion and completed documentation/import from Wikipedia: good work!
    I wonder if it was just the tip of an iceberg.
    --- Jura 14:00, 7 June 2016 (UTC)
  • If you find a property with low usage, I imagine the easiest way is probably to just import some data yourself (lots of properties correspond to template parameters but we didn't have the tools for users to easily import data from templates until recently). The more data we have, the more visible it becomes (people will see it on items, the property suggester will start suggesting it) and the more likely it becomes that other people will start using it. If, for whatever reason, that's not possible, there's the bot requests page, relevant wikiprojects or even project chat. I don't think this is the right place though because there's no minimum usage requirement for properties. - Nikki (talk) 14:16, 7 June 2016 (UTC)
    • Well properties are created to be used. If even the proposer can't come up with sensible uses, it's likely we add overhead for nothing.
      --- Jura 14:58, 7 June 2016 (UTC)
• Template:Keep This is one of the parameters of Template:Q which is used by quite a few projects. - Nikki (talk) 14:16, 7 June 2016 (UTC)
• speedy keep, as everybody is satisfied now/the main concerns are resolved? --Edgars2007 (talk) 15:35, 7 June 2016 (UTC)

Property:P2901

One day I'll learn to use the correct datatype ... (You could also repurpose this for a new item property.) Srittau (talk) 13:19, 12 June 2016 (UTC) Template:Discussion bottom

Template:P

Not sure if this is of much use, see Wikidata:Property_proposal/property_usage_tracking_category#P2875 for discussion. --- Jura 16:18, 29 May 2016 (UTC)

• Template:Keep, enough consensus existed. Jura, stop your Kindergarten-style passive-aggressive warfare and concentrate on constructive behavior. Thanks. --Srittau (talk) 16:26, 29 May 2016 (UTC)
  • There was no support for Izno's amended proposal. I don't see where you are reading that. If you resort to personal attacks each time people disagree with you, this is not helpful.
    --- Jura 16:31, 29 May 2016 (UTC)
    • Throwing out deletion requests, because you didn't get your will 100% is really, really childish. I see them as a personal attack on my work and myself. As I said in my property creation comment: Please discuss the details of this property on the property talk page. If, after half a year or so, this property has gained no traktion, it can still be deleted. --Srittau (talk) 16:43, 29 May 2016 (UTC)
      • You need to attempt to assess the consensus in a proposal discussion. If you feel that you are attacked in your person if people disagree with your work, you might want to avoid such proposals. Makes me wonder if you actually tried to index such categories.
        --- Jura 16:50, 29 May 2016 (UTC)
• What's wrong with using Template:P with some criteria items to indicate different types of tracking subcategories here? Lymantria (talk) 11:11, 30 May 2016 (UTC)
  • Hence Template:Keep Lymantria (talk) 10:44, 1 June 2016 (UTC)
  • If neither the creator nor the proposer can explain it, shouldn't it be deleted?
    --- Jura 10:48, 1 June 2016 (UTC)
    • If the proposer for deletion can't explain why his support vote in the proposal for creation was to be neglected, shouldn't it be kept? This type of questions on personal issues are not helpful. Lymantria (talk) 08:37, 2 June 2016 (UTC)
      • Icons in discussions are somewhat misleading, especially when the proposal is revised thrice since it was first formulated. In any case, here the chronology makes it easy: none supported Izno's amended proposal. Worse, it's clearly not in line with the recent variants > Template:Vote delete
        --- Jura 10:26, 2 June 2016 (UTC)
        • Icons may be somewhat misleading, it reflects that you didn't oppose to the single property proposal it started with. You even suggested how to use it in answer to Pasleim, together with a suggestion to split the property. The next day you changed the proposal according to this second suggestion. This new suggestion did not gain any support, but Izno explicitly rejected it, while supporting the original proposal. In that view I would come to the exact same conclusion as Srittau did: consensus to create this property. While labels like "childish" do not help, this deletion proposal and the way you try to give a twist to the facts are not in my view very helpful for the cooperation we all have on this project, but more reflect what Template:Q tries to prevent. Please show some respect for the decision that Srittau has taken here. We all know what it is with properties: it is not easy to see beforehand how things will work out and we have to try and amend if necessary. Yours, Lymantria (talk) 13:24, 2 June 2016 (UTC)
          • I guess we are somewhat used to this type of comment by Srittau, but I don't think it's helpful nor particularly suitable for someone who had to assess the consensus in a proposal discussion. It really disrupts the assessment of the property deletion.
            Please note that the property that was created wasn't in line with the samples in the proposal nor with your comment above. Personally, I really don't see where I supported the proposal with a single value constraint that was created. Maybe you could provide me with a diff. Obviously, if Izno already has a plan to make use of the created property, I'd be happy to comment and possibly support it.
            --- Jura 14:21, 2 June 2016 (UTC)
            • The single value constraint was explicitly by Srittau brought into discussion, that should be on the talk page. Your action frustrates possible discussion. Please note that. Lymantria (talk) 14:26, 2 June 2016 (UTC)
              • This could mean that implicitly he acknowledges that there may be no consensus for the property he created? The result of this may be that we should formulate new proposals each time we come across an improvement and explicitly oppose anything that doesn't exactly match it. Not sure how this improves discussion. Maybe the creation was just premature. Let's delete it and re-open the discussion.
                --- Jura 15:07, 2 June 2016 (UTC)
                • Not on my behalf. Lymantria (talk) 17:24, 2 June 2016 (UTC)
• Keep property and as single value: " Obviously, if Izno already has a plan to make use of the created property, I'd be happy to comment and possibly support it." <- is unnecessarily combative. The single value constraint will do 0 to stop you from using it; it will just limit how you use it to the "most important" category. As has been argued ad nauseum on several other proposals and which seems to be the sitting consensus, we are not here to categorize the projects' categories. If they can't do that job themselves, that's their problem, not ours. --Izno (talk) 15:34, 2 June 2016 (UTC)
  • Please keep us updated about your plan.
    --- Jura 15:42, 2 June 2016 (UTC)
    • Please keep us updated on how you're basically rolling over and giving up on this PFD. :) --Izno (talk) 15:55, 2 June 2016 (UTC)
• Template:Keep. I was deploying this property when i found this discussion. Thierry Caro (talk) 17:07, 10 June 2016 (UTC)
  • Seems you also converted property Template:P we had previously to Template:P. In that case, we should keep this.
    --- Jura 09:05, 11 June 2016 (UTC)
    • Template:Keep --Mr. Ibrahem (talk) 19:56, 11 June 2016 (UTC)
• Template:Keep IMO useful metadata. Matěj Suchánek (talk) 17:11, 25 June 2016 (UTC)
• Template:Keep. And Jura, stop making disruptive deletion requests. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:15, 7 July 2016 (UTC)

Property:P2932, Property:P2933, Property:P2934

See WD:AN. --Yair rand (talk) 18:05, 23 June 2016 (UTC)

• Template:Vote delete No discussion and no explanation about the use of these properties. Snipre (talk) 18:33, 23 June 2016 (UTC)
• Template:Vote delete all possible meanings of broader and narrower are covered by existing relations - subclass, instance, part of. ArthurPSmith (talk) 19:02, 23 June 2016 (UTC)

Deleted. Created out of process. We had a huge discussion the last time this happened and the consensus was that's it's not ok to create properties outside of the process because it denies the community the possibility to comment on property proposals. You're more that welcome to propose these properties. If consensus is reached that we need these properties, the properties can be undeleted. Multichill (talk) 13:18, 24 June 2016 (UTC)

Property:P2541

Propose to merge with Template:P and rename it to "places served". GZWDer (talk) 20:41, 2 August 2016 (UTC)

• Template:Oppose This was suggested and rejected when Template:P was proposed. If it is merged "places served" is not a good label as P2541 includes areas that are not "served" - e.g. Template:Q does not "serve" Template:Q rather it is jointly responsible for investigating accidents that occur there, and Template:Q doesn't serve Template:Q rather it is an umbrella organisation that supports its members wherever they are in the world. Thryduulf (talk) 00:29, 3 August 2016 (UTC)

Property:P3062

Wrong datatype GZWDer (talk) 18:53, 9 August 2016 (UTC) Template:Discussion bottom

Template:PfD

The property Property:P2608 (Valencian Property of Local Relevance id) seems a duplicate of Template:P, as both represent Template:Q. As Template:P is more complete, I've just substituted the only item using Template:P (the property example Template:Q) to the older one, and propose the newer one for deletion. The property is not used in the external template indicated (ca:Plantilla:Infotaula edifici). —surueña 07:46, 17 August 2016 (UTC)

Template:Ping ping property proposers --Pasleim (talk) 08:35, 17 August 2016 (UTC)

Thanks, Template:Ping.--Amadalvarez (talk) 09:27, 17 August 2016 (UTC)

Template:Support It's really the same. I've copied the "source" in the older's description page from the Template:P to incorporate the heritage official inventory. The rest of information is similar. --Amadalvarez (talk) 09:27, 17 August 2016 (UTC)

I agree.--KRLS (talk) 08:55, 18 August 2016 (UTC)

Property:P3247

Accidental duplicate of Property:P3248 AVRS (talk) 04:26, 4 October 2016 (UTC) Template:Discussion bottom

Template:PfD

It seems to me that this property was created without consensus; see Wikidata:Property proposal/property used--Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:55, 18 September 2016 (UTC)

Please notify the involved people, there is no mention on the property talk page or proposal. Sjoerd de Bruin (talk) 16:47, 19 September 2016 (UTC)

• Template: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. ArthurPSmith (talk) 13:45, 22 September 2016 (UTC)

Template:Ping --ValterVB (talk) 17:25, 22 September 2016 (UTC)

• Template:Keep Disagree with Andy's conclusion about missing consensus. Furthermore I consider the property useful. Lymantria (talk) 21:24, 22 September 2016 (UTC)
• Template: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. Template:Q it's clear that Template:P is not an appropriate property for this use case, and I'm not aware of any other existing or proposed ones that are. Thryduulf (talk) 21:35, 22 September 2016 (UTC)

---

• Kept no grounds or consensus for deletion at all. Multichill (talk) 15:25, 7 October 2016 (UTC)

Template:PfD

Template:Rfd links Currently we have 3 properties to describe languages of an item (Template:P, Template:P and Template:P). This discussion aims to delete Template:P in favour of an unique property for language Template:P.

There was already a discussion about deletion of these properties and decisions have to be taken on a logic way as properties are the ground of classification in Wikidata:

• If there is an original language, we have to keep a symetric classification with an original publisher, an original publication date,...
• FRBR system is the ground of the classification in wikidata for work and was adopted through a RfC Snipre (talk) 00:35, 7 June 2016 (UTC)

Template:Ping Can you reopen the discussion as the previous discussion was closed ? Snipre (talk) 16:23, 11 June 2016 (UTC)

Template:P, Template:P, Template:P and Template:P

These ID's are essentially the same, as all links created redirect into https://catalog.archives.gov/id/$1. Template:P seems to be the most used (although still not extensively) and most generic of these properties. The others can be merged into it. --Lymantria (talk) 20:53, 3 September 2016 (UTC)

• Template:S the merge. --Fralambert (talk) 20:59, 3 September 2016 (UTC)
• Template:S merge. --Pasleim (talk) 22:11, 3 September 2016 (UTC)
• Template:S If the formatter URL is indeed the same for all, then I agree on merging them. Mbch331 (talk) 09:05, 4 September 2016 (UTC)
• Template:S merge.--Jklamo (talk) 20:13, 18 September 2016 (UTC)
• Template:Ping completely forgot about these. Talked with user:Dominic about this some time ago, see User talk:Dominic#NARA properties. I think it's save to merge all of them into one property. Multichill (talk) 19:20, 5 October 2016 (UTC)
  • Template:Ping Very good, but I don't think I should handle my own deletion proposal. Lymantria (talk) 19:28, 5 October 2016 (UTC)
    • I deleted the properties. I think the last step is to migrate from Template:P to Template:P. Multichill (talk) 15:20, 7 October 2016 (UTC)

      Template:Ping can you please label the deleted properties? Thanks.  — billinghurst sDrewth 06:55, 5 November 2016 (UTC)

Template:PfD

Sorry, I created a property instead of an item.--— Ayack (talk) 15:31, 12 September 2016 (UTC)

deleted --Pasleim (talk) 15:49, 12 September 2016 (UTC)

Property:P3244

Duplicate of Property:P3245 AVRS (talk) 17:22, 2 October 2016 (UTC)

Thanks, I think I will put the next approved authority into those IDs. ChristianKl (talk) 17:48, 2 October 2016 (UTC)

Please don't reuse entities. Sjoerd de Bruin (talk) 18:08, 2 October 2016 (UTC)

Those duplicate properties have never been used; they were just created (two announced, two their duplicates). --AVRS (talk) 19:16, 2 October 2016 (UTC)

Can you either re-use now or have it speedy deleted? Otherwise it would have ended up with the similar label in the weekly update.
--- Jura 10:32, 3 October 2016 (UTC)

I deleted P:P3244 and P:P3249. Entities should not be reused, especially not when they are older than a few hours. The work to create a new property compared to reuse a property is marginal. --Pasleim (talk) 15:24, 3 October 2016 (UTC)

Template:PfD

The BBC have withdrawn this identifier. All uses now divert to a generic parliament page. The example, Tom Watson, http://news.bbc.co.uk/democracylive/hi/representatives/profiles/25228.stm now lands at http://www.bbc.co.uk/news/politics/parliaments Issue raised at : en:Template talk:UK MP links#BBC News Democracy Live -- Cabayi (talk) 10:15, 6 October 2016 (UTC)

• Keep As a point of principle we should not be deleting data just because it is no longer in use. Simply remove the formatter URL (or use one at archive.org; e.g. [8]) and add a note to the talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:25, 6 October 2016 (UTC)
  • I added the archive.org formatter URL and the original is deprecated, but it looks like the wikidata UI is still pointing to the old one for the external id. Is this a bug? ArthurPSmith (talk) 13:22, 7 October 2016 (UTC)
    • Purging the cache seemed to do the trick, but I've marked the archive version as preferred anyway. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:11, 7 October 2016 (UTC)

Property:P3287

This looks like a duplicate of Property:P3286. Korg (talk) 02:51, 13 October 2016 (UTC)

Template:Deleted --Pasleim (talk) 08:23, 13 October 2016 (UTC)

Property:P3312

Duplicate property ChristianKl (talk) 19:17, 31 October 2016 (UTC)

Property:P3313

Duplicate property ChristianKl (talk) 19:17, 31 October 2016 (UTC)

Template:PfD

A duplicate of Property:P3317 --Chrumps ► 21:03, 11 November 2016 (UTC)

Property:P3317

Duplicate property ChristianKl (talk) 22:53, 14 November 2016 (UTC)

Template:PfD

Wrong datatype--Almondega (talk) 13:30, 23 November 2016 (UTC)

Template:Done --Pasleim (talk) 13:04, 25 November 2016 (UTC)

Template:PfD

It is not used, couldn't find a single statement using it--Marfi (talk) 12:50, 25 November 2016 (UTC)

Template:Keep it is used as qualifier on Template:P=Template:Q [9]. --Pasleim (talk) 12:58, 25 November 2016 (UTC)

Template:Keep agree. It is not used as Property, only as qualifier. --Marfi (talk) 13:03, 25 November 2016 (UTC)

Template:Keep clearly appropriate and needed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:34, 26 November 2016 (UTC)

Template:PfD

Zero instances as property or as qualifier.--Marfi (talk) 07:49, 30 November 2016 (UTC)

Invalid request. This is totally out of context and the proposer did not made the effort to provide any. This seems to me only an attempt to raise a stick to try to force somebody to add datas. But a proposal like this for a single property where the property is probably a part of a larger set of properties aimed to consistently represent something may make broke a leg to the model concerning this something. As a consequence I'll ask Template:U' to provide context and rationale for this proposal. author  TomT0m / talk page 11:40, 30 November 2016 (UTC)

Context and rationale: Property created in July and haven't been used even once. --Marfi (talk) 11:54, 30 November 2016 (UTC)

This is not an answer to my comment. author  TomT0m / talk page 11:57, 30 November 2016 (UTC)

• Properties are created to be used. If even the proposer can't put it to use, it's unlikely to ever happen. It happens that proposals don't quite work out how we expected and so we don't use them. No need to keep maintaining though.
  --- Jura 12:09, 30 November 2016 (UTC)
  • It happens that proposals don't quite work out how we expected and so we don't use them => This deletion prop, by lack of context, does not provide any mean to juge that. Besides, a few weeks of month is not quite a lot in a volunteer world where a contributor can disappear a few weeks or month (or years) before coming back to continue its plan. If he or she can't take his plan where (s)he left it, it will have to startover, which can be quite depressing. For the maintenance burden : if an unused property is a burden to maintain, then our maintenance process has clearly something that has to be improved (once more, the "property by property" stuff is the wrong granularity. We usually need several properties to make a model work, it's a waste of time to consider stuffs property by property). author  TomT0m / talk page 12:22, 30 November 2016 (UTC)
    • I can understand that people who don't do maintenance, don't care about maintenance, but creating properties does generate overhead. There isn't really a sensible way to judge the usefulness of the property as it unused, even by the proposer. I'm sure we can find another site for useless properties. Maybe test.wikidata.org .
      --- Jura 12:54, 30 November 2016 (UTC)
      • Caring about maintenance does not mean you don't have to answer the concerns of others. Maintenance is not everything here. author  TomT0m / talk page 13:19, 30 November 2016 (UTC)
        • It's not clear what your concern is other than that the non-contributor may be depressed by not being able to (not-)use the property they are not using ..
          --- Jura 14:18, 30 November 2016 (UTC)
          • I think I made my concerns pretty clear. But to be more explicit : creating a property in Wikidata is a burden. I don't really think we already had a discussion about re-creating a property but I pretty much well see Jura1 arguing "this property has been deleted, I want extra extra care now not to oppose its recreation". So if no better argumentation, as far as I concerned, we might be digging a hole into current Wikidata data model that would have to be refilled later with more difficulty. For what ? Just because the proposer had no time for a few month to use the property and it increased the "maintenance burden" of a few milliseconds ? Sorry, but no. author  TomT0m / talk page 14:45, 30 November 2016 (UTC)
• Template:O. Insufficiently motivated, see discussion above. This property is defined and should be available to anyone needing it. author  TomT0m / talk page 14:45, 30 November 2016 (UTC)
• Template:Ping any comments on the above, as proposer of the property? ArthurPSmith (talk) 20:40, 30 November 2016 (UTC)
  • Thank you, ArthurPSmith. Tubezlob (🙋) 17:42, 2 December 2016 (UTC)
• Template:O Agree with TomT0m. See Wikidata_talk:WikiProject_Association_football/Euro_2016#Points_of_penalty and Wikidata:Property proposal/point of penalty, and I added this property for two items: Template:Q and Template:Q. It's not because it is not use a lot at this moment that we have to delete it. Tubezlob (🙋) 17:42, 2 December 2016 (UTC)

This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:04, 8 December 2016 (UTC)

Template:PfD

Duplicate of Template:P, now unused.--Fralambert (talk) 02:18, 4 December 2016 (UTC)

Template:Ping can you confirm? You proposed P2081, but never put it to use.
--- Jura 03:11, 4 December 2016 (UTC)

• Delete Should we even discuss such cases? --90.152.69.99 12:36, 7 December 2016 (UTC)

Template:Ping is P2081 up for deletion as well?? --Marfi (talk) 12:40, 7 December 2016 (UTC)

This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:26, 8 December 2016 (UTC)