Wikidata:Properties for deletion/Archive/2016

This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

input set (P1851)

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. ~~Delete~~ unless @TomT0m, Danneks, Cuvwb: can shed some light on this. Filceolaire (talk) 10:35, 3 June 2015 (UTC) Vote changed - see discussion below. Joe Filceolaire (talk) 20:03, 27 October 2015 (UTC)

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

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

@Filceolaire, AS: It's the A set in this mathworld definition. It's commonly used for example for the inverse function on the real, who has no value in R for 0, but still has R as input set, for example. The real domain of the function is nonzero real number (Q19546578)  

. TomT0m ^(talk) 11:22, 6 June 2015 (UTC)

what is the difference between definition domain (P1568) and input set (P1851)? Can you provide an example when definition domain (P1568) is not enought? -- Vlsergey (talk) 20:15, 16 June 2015 (UTC)

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

@TomT0m: let me make it clear. You want to express that

⟨ subject ⟩ definition domain (P1568) ⟨ nonzero real number (Q19546578)  

 ⟩

and

⟨ subject ⟩ input set (P1851) ⟨ real number (Q12916)  

 ⟩

, right? But we have

⟨ nonzero real number (Q19546578)  

 ⟩ subclass of (P279) ⟨ real number (Q12916)  

 ⟩

. Why do we need to duplicate that in function itself? -- Vlsergey (talk) 20:55, 16 June 2015 (UTC)

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

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

I have many example of non total functions, halting problem (Q622849)  

involves a HALT function which is from programs to 1,0 which has programs as input set but is undecidable. partial function (Q1756942)  

provides other examples. The notion of domain is also non applicable for relations ( partial order (Q1069998)  

) like 1<2 or other binary relation (Q130901)  

. 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,

Keep.--Jasper Deng (talk) 22:06, 13 August 2015 (UTC)

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

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

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

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

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

It's difficult for me to write english. So please, be kind with me and improve my text. There is a difference between set of departure and domain. The set of departure is defined for a binary relation(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. @Succu:In 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.

Keep for me HB (talk) 13:57, 15 August 2015 (UTC)

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

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

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

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

@Filceolaire: Properties are not functions, they are relation (Q203066)  

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

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

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

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

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

@Filceolaire:. This property is already used in tangent (Q1129196) and cotangent (Q1264373). What would put as domain in theses cases? HB (talk) 16:54, 18 August 2015 (UTC)

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

@Filceolaire: The domain of a function, by definition, is the set of all "permitted inputs", for which the function has a value. The cotangent function, for example, is not defined at zero, because

{\tfrac {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)

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

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

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

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

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

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

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

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

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

Keep. I have slightly modified the description to

a superset of the domain of a function or relation that may include some inputs for which the function is not defined; to specify the set of only those inputs for which the function is defined use domain (P1568)

. By the way, the number of items using this property is rising. ;-) Can we close this PfD now? Petr Matas 08:09, 4 January 2016 (UTC)

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

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

officeholder (P1308)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Consensus to keep. While some cases - such as the one raised by Yair rand - should be avoided, there seem to be legitimate uses for this property, and a critical mass of users supporting its retention. Ajraddatz (talk) 04:25, 4 March 2016 (UTC)

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

Pinging original proposer @Jdforrester: and property creator @Jakec:. (Apparently the property_proposer and property_creator parameters in Template:Request for deletion don't actually do anything.) --Yair rand (talk) 09:43, 14 June 2015 (UTC)

Delete With arbitrary access rolling out, this property should be deleted. —Wylve (talk) 13:13, 17 June 2015 (UTC)

Comment there is actually a third way doing more or less the same: head of government (P6) and head of state (P35).
officeholder (P1308) has the advantage of not overloading items for countries as does head of government (P6).
position held (P39) does work well to make lists like Governors of Vermont --- Jura 09:54, 18 June 2015 (UTC)
Keep; P6 and P35 are inappropriate for the wider needs, as widely discussed at the time. Individuals' unwillingness to help build the data right now isn't a good criterion for whether we should have the flexibility to express it. James F. (talk) 02:28, 22 June 2015 (UTC)
@Jdforrester: This is redundant to position held (P39), not head of government (P6) and head of state (P35). Many offices (though not, afaik, offices of head of state/government) have been held by thousands of people. --Yair rand (talk) 11:36, 22 June 2015 (UTC)
@Yair rand: San Marino elects at least 4 head of states every year. And Stockholm has 12 kommunalråd. -- Innocent bystander (talk) 13:12, 15 July 2015 (UTC)

@Yair rand: Except it's precisely the ontological reverse of position held (P39), which allows us to model more complex things (like parallel office holders, pretenders, etc.). James F. (talk) 00:41, 28 June 2015 (UTC)
I don't understand what you're saying. (This is probably because I don't recognize the term "ontological reverse".) Do you disagree that this is just a simple inverse of position held (P39), and adds no new data? If so, could you give an example of data this property could be used for that position held (P39) couldn't be used for? --Yair rand (talk) 16:53, 28 June 2015 (UTC)
If it is the inverse of another property it adds new data per definition. If A is connected to B by one property B is connected to A by its inverse, so deleting the inverse would require another inverse propery to replace it. - cycŋ - (talk • contribs • logs) 12:18, 15 July 2015 (UTC)
No, it would not. Properties are not required to have inverse properties. This inverse in particular is completely unmanageable. --Yair rand (talk) 18:19, 15 July 2015 (UTC)
@Yair rand: While you are totally right concerning proper database design, Wikidata is currently not working this way (at least for what I can tell). Giving an easy example: I want to find out the Mayor of New York. The corresponding item is Mayor of New York City (Q785304). With officeholder (P1308) I can find out the current Mayor is Bill de Blasio (Q4911497), but how could I find out if officeholder (P1308) was deleted? (Still, from Bill de Blasio (Q4911497) I could find out that he is Mayor of New York by position held (P39), but I'm looking for de Blasio, so I indeed need the inverse way.) // Keep as long as the inverse view is not implemented properly in the Wikidata MediaWiki software. Yellowcard (talk) 12:39, 16 October 2015 (UTC)

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

While I don't like the property as it is unclear that it reverse "position held" it could be useful for periods of interregnum to state "vacant", similarly occasions when it is browsed data, gaps will be more obvious and invite someone to fill. I would like to see how it is proposed to be used for pretenders. @Jdforrester: an example would be helpful to further the argument.

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

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

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)

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

after a work by (P1877) etc.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

No consensus for deletion, and some good reasons presented to keep. Ajraddatz (talk) 03:10, 7 February 2016 (UTC)

Really, the whole set after a work by (P1877) / circle of (P1776) / follower of (P1775) / influenced by (P737) / inspired by (P941) / manner of (P1777) / school of (P1780) / workshop of (P1774) seems like it could be compressed into fewer properties. There are some distinctions in there, but the boundaries are pretty fuzzy. I think after a work by (P1877) in particular is redundant to inspired by (P941), but the whole lot merits discussion. Maybe someone with an art history background could propose a way to simplify the situation without loss of information. --Swpb (talk) 22:00, 6 January 2016 (UTC)

P1775 and P737 definitely appear to be duplicates. Agreed re 1877 and 941, and probably 1777 (I see little reason to use a property to indicate that the time delta between artists is interesting when the information associated with the particular artist can be derived from lookingup the artist). 1774 strikes me as likely having a duplicate but not any of the others provided in your original request.

It seems a number of these qualifiers are for use with the statement creator -> "anonymous" to clarify who that anonymous person might be (but for whom we cannot guarantee is the case), so indeed, I think there may be other ways to assert this information. --Izno (talk) 12:53, 12 January 2016 (UTC)

Ok then, I propose the following:

Merge follower of (P1775) / circle of (P1776) / manner of (P1777) / school of (P1780) / after a work by (P1877) to the generic influenced by (P737).
Merge P1773 (P1773) and possible creator (P1779) (either label is fine)
Leave workshop of (P1774) alone, since it expresses membership in a somewhat formal group, rather than inspiration per se (subtle distinction).
Change label of inspired by (P941) to "inspired by work" to reflect its current description and separate it from the above parameters, in which the subject is an artist.

Swpb (talk) 17:30, 12 January 2016 (UTC)

@Sjoerddebruin, Michiel1972, Pigsonthewing, Spinster, TomT0m, Oursana: @Giftzwerg 88: As people who have previously commented. --Izno (talk) 18:36, 12 January 2016 (UTC)

Thank you. I suspect these are all needed, but will await comment from art historians. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:14, 12 January 2016 (UTC)

Thanks. Could you point us to these previous discussion(s)? I'd like to see what sort of arguments were made. Swpb (talk) 21:36, 12 January 2016 (UTC)

Discussions are on proposal pages, and we should set up a grid with examples on the SoaP page or probably better - Visual Arts page. --Jane023 (talk) 11:06, 13 January 2016 (UTC)

I think these are all needed and do not understand how you could merge them without making lots of qualifiers. "After a work by" is a copy, not to be used when you have two similar versions and are unsure if they are copies. In that case you can use "different from" to show they are distinct, but not necessarily copies. You may feel these are nuances, but in certain circles calling something a copy degrades its value by quite a bit. Similarly "inspired by" is very different from "follower of" b/c one refers to the work and the other to the artist. I think we need to keep these as they are used by the official thesaurus of the Getty. We could and should document use better, because otherwise we will create a big mess. Not sure if we already have one or not. --Jane023 (talk) 21:39, 12 January 2016 (UTC)

Keep standard way of describing works, compressing it into fewer properties would be original research. Multichill (talk) 21:52, 12 January 2016 (UTC)
Keep--Oursana (talk) 03:36, 13 January 2016 (UTC)
Keep Art historian chiming in. These properties may sound superfluous to outsiders, but have essentials differences in the way artworks are attributed in our profession/field. We have created these properties based on advice from the Rijksmuseum. For an overview of definitions and distinctions widely accepted by the art history and museum community, see these artwork description guidelines by the Getty. As volunteers dedicating a lot of serious time and attention on artworks here on Wikidata, we want to be taken seriously by collection managers from major museum collections and we want to be in line with their level of quality control. Spinster (talk) 11:28, 13 January 2016 (UTC)
Comment @Jane023, Multichill, Oursana, Spinster: There's apparently a consensus that these parameters are distinct, but their definitions fail to show how they are distinguished. Jane's statement that "we could and should document use better" cannot be emphasized enough - to the uninitiated, these properties are utterly indistinguishable. I hope that one or more of you knowledgeable editors will take on that task. With that thought, I'm out. Swpb (talk) 15:55, 13 January 2016 (UTC)
- Looks like this has been started here Wikidata:WikiProject_Visual_arts/Item_structure#Use_of_creator_.28P170.29_in_uncertain_cases --Jane023 (talk) 11:27, 14 January 2016 (UTC)
Keep A note: There does not seem to be a one-to-one correspondence between Wikidata and Getty. Getty has "after: Use for a work by an unknown artist who has created a copy of a known work of the named artist", but it seems that you can use after a work by (P1877) for a known artist copying a known work of a named artist. — Finn Årup Nielsen (fnielsen) (talk) 19:57, 22 January 2016 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Ryan Coogler (Q22673763)

Ryan Coogler (Q22673763): American filmmaker: (delete | history | links | entity usage | logs)

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

Does not belong here,

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

Property:P2569

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Property deleted. Lymantria (talk) 07:09, 24 March 2016 (UTC)

P2569 (P2569): (delete | history | links | entity usage | logs)

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

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)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P2616 (P2616)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Deleted by User:Ajraddatz --Srittau (talk) 02:48, 25 March 2016 (UTC)

P2616 (P2616): (delete | history | links | entity usage | logs)

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)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

opposite of (P461)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

consensus to keep --Pasleim (talk) 23:26, 22 March 2016 (UTC)

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)

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

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

Some example taken from 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)

@Izno: Yes, it's good to find good and accurate examples :) Actually it's the proposed

Under discussion

Description	MISSING
Data type	MISSING
Example 1	MISSING
Example 2	MISSING
Example 3	MISSING

disjoint union of (partitioned into?) that would fit here :

⟨ human (Q5)  

 ⟩ disjoint union of (P2738) ⟨ Woman ⟩
together with (P1706) ⟨ Man ⟩
together with (P1706) ⟨ Intersex ⟩

. It's not approved yet thought, although there is a lot of example of use cases here. author TomT0m / talk page 09:29, 16 August 2015 (UTC)

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

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

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

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. @AVRS, Tobias1984: 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 approved by (P790)). I don't know about color models, but there is "gender binary (Q5530970)". --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 Gibraltar (Q1410) and Te Ārai (Q7690759), which are merely antipodes on the globe. It is clarified with a instance of (P31) antipode (Q319909) as a qualifier, I'm not sure it is the right way to indicate it, but something like that should be added, by obligation IMHO. If so, I say

Keep. Lymantria (talk) 17:51, 29 August 2015 (UTC)

There is just such a qualifier: criterion used (P1013), and I agree it should be mandatory. In your example, a better qualifying statement would be criterion used (P1013) geographic coordinate system (Q22664), but "antipode" might be sensibly proposed as a subproperty of opposite of (P461) Swpb (talk) 15:20, 29 December 2015 (UTC)

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

I suggest reading en:Opposite_(semantics)#Antonyms. Opposite can mean different things. Probably this property could be made more exact using qualifiers to state what kind of oposition it means in each statement, or it could be split in more precise properties. Anyway, in its present state it isn't machine-readable (as Wikidata should be) because it's need a human decide it's meaning in each item. It's more a trivial section than a fact statement - it doesn't harm but I don't see it very useful as of now.--Pere prlpz (talk) 17:47, 6 November 2015 (UTC)
@Pere prlpz: Everything is in the "Word" in the "pair of words". Wikidata do not speak of words at this point, this is for Wiktionary. For some cases here, we use opposite for the "complement" notion (I simplify for the example : (for simplification I just ignore the LGBT and co. cases at first) : "every human is either a man or a woman". To express this, at this point, some people on Wikidata would use "man : opposite : woman". In the proposition "
Under discussion
Description MISSING
Data type MISSING
Example 1 MISSING
Example 2 MISSING
Example 3 MISSING
" 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)
Keep But I have encountered plenty of claims which don't make sense to me. For example, monohull (Q1999103) has been claimed to be the opposite of multihull (Q1642862). Perhaps something has been lost in translation? Danrok (talk) 16:02, 18 December 2015 (UTC)
Keep, but require qualifier criterion used (P1013); create subproperties like antiparticle (P2152) as warranted. Swpb (talk) 15:12, 29 December 2015 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

structure replaces (P1398)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

consensus to keep --Pasleim (talk) 23:27, 22 March 2016 (UTC)

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)

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

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P1569 (P1569)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

consensus to delete --Pasleim (talk) 07:36, 30 March 2016 (UTC)

P1569 (P1569): (delete | history | links | entity usage | logs)

P1570 (P1570)

P1570 (P1570): (delete | history | links | entity usage | logs)

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

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

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

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P1221

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

no consensus to delete --Pasleim (talk) 07:37, 30 March 2016 (UTC)

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

Oppose. compressor type (P1221) is clearly not "unused", and is not for instance of (P31). For example, Westinghouse J30 (Q7988946), which has this property, is a "subclass of" turbojet (Q723916) and aircraft engine (Q743004) and not an "instance of" axial compressor (Q742777). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:47, 29 December 2015 (UTC)
@Pigsonthewing: would my suggestion below change your oppose? --Izno (talk) 18:37, 12 January 2016 (UTC)
Delete - instance of (P31) is not the correct property of replacement, however. The correct one would be has part(s) (P527). 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)
Keep: It seems its only sin is to be as yet underused. instance of (P31) is not a valid substitute, but has part(s) (P527) may work. Still, I don't see any value to deleting it. Josh Baumgartner (talk) 18:30, 5 January 2016 (UTC)
Keep Maybe underused, but clearly defined sub-property of has part(s) (P527). Using pronunciation variety (P5237) would be ambiguous, if not used with qualifiers. --Srittau (talk) 02:41, 25 March 2016 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P1887

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Property deleted. Multichill (talk) 21:30, 18 March 2016 (UTC)

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

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

Delete@Thryduulf: 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 vice-county (P1887) is misused, but there are certainly dormant properties which are wrongly used on a regular basis (my favorite is relation (P2309)). 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 vice-county (P1887) 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)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P2466 (P2466)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

consensus to delete --Pasleim (talk) 07:38, 30 March 2016 (UTC)

P2466 (P2466): (delete | history | links | entity usage | logs)

Seems to be a duplicate of penalty (P1596) 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)
Delete almost same meaning as penalty (P1596), used only six times. --Jklamo (talk) 19:40, 25 March 2016 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P2653

P2653 (P2653): (delete | history | links | entity usage | logs)

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

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

Property:P2654

P2654 (P2654): (delete | history | links | entity usage | logs)

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

P2706 (P2706): (delete | history | links | entity usage | logs)

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

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

Wikidata example properties

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

consensus to delete these properties --Pasleim (talk) 19:40, 27 April 2016 (UTC)

P1856 (P1856) P1856 (P1856): (delete | history | links | entity usage | logs)
P1858 (P1858) P1858 (P1858): (delete | history | links | entity usage | logs)
P1859 (P1859) P1859 (P1859): (delete | history | links | entity usage | logs)
P1860 (P1860) P1860 (P1860): (delete | history | links | entity usage | logs)
P1861 (P1861) P1861 (P1861): (delete | history | links | entity usage | logs)
P1862 (P1862) P1862 (P1862): (delete | history | links | entity usage | logs)
P1863 (P1863) P1863 (P1863): (delete | history | links | entity usage | logs)
P1864 (P1864) P1864 (P1864): (delete | history | links | entity usage | logs)
P1865 (P1865) P1865 (P1865): (delete | history | links | entity usage | logs)

I proposed these before I realised there is a better way of recording examples, using Wikidata property example (P1855); 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)

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

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

@TomT0m: There are also sandbox properties Sandbox-CommonsMediaFile (P368), Sandbox-Item (P369), Sandbox-String (P370), Sandbox-TimeValue (P578), Sandbox-GeoCoordinateValue (P626), Sandbox-URL (P855), Sandbox-Quantity (P1106), Sandbox-Monolingual text (P1450) --Pasleim (talk) 20:55, 16 August 2015 (UTC)

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

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

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

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

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

@Filceolaire: Does Sandbox-Property (P2368) satisfy this, for you? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:57, 5 January 2016 (UTC)

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

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

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

@GZWDer: I created Sandbox-Property (P2368) as sandbox property with datatype property. --Pasleim (talk) 22:10, 30 November 2015 (UTC)

@GZWDer: Does Sandbox-Property (P2368) satisfy this, for you? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:57, 5 January 2016 (UTC)

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

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

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)

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

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

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

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

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

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

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

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

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)

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)

@Matěj Suchánek: "Is there any chance on closing this soon" 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)

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

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

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)

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)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P1790 (P1790)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

consensus to delete --Pasleim (talk) 19:43, 27 April 2016 (UTC)

P1790 (P1790): (delete | history | links | entity usage | logs)

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)

WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. --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)

Delete 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 Extracting scientific articles from a large digital archive: BioStor and the Biodiversity Heritage Library (Q21093653) BioStor (Q18586574) 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:BioStor (Q19253027) 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)

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

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 ORCID iD (Q51044), International Standard Name Identifier (Q423048), or, indeed, Wikidata item (Q16222597). 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)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P2617 (P2617)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

consensus to delete --Lymantria (talk) 20:46, 2 May 2016 (UTC)

@Pigsonthewing: 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)

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)

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)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

language of work or name (P407) and original language of film or TV show (P364)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

I close this deletion proposal as undecided, because of change of basis of the proposal. Its basis changed since P2439 (P2439) was created earlier this year. Both properties are kept for now, but new deletion proposals may be started accounting the the existance of P2439 (P2439). Lymantria (talk) 17:51, 7 June 2016 (UTC)

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

@Danrok, Kolja21, Wikijunkie, Nightwish62:

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)
original language of film or TV show (P364) vs. language of work or name (P407). Snipre (talk) 00:58, 11 January 2015 (UTC)
So you want ot merge original language of film or TV show (P364) and language of work or name (P407). Since original language of film or TV show (P364) is more specific than language of work or name (P407), 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 original language of film or TV show (P364) instead of/and not language of work or name (P407). Visite fortuitement prolongée (talk) 20:16, 11 January 2015 (UTC)
Visite fortuitement prolongée I am pragmatic: use of original language of film or TV show (P364): 95129, use of language of work or name (P407): 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 language of work or name (P407) is used also for other types of entities, for example, in names. Which is not easily convertible to original language of film or TV show (P364). --Infovarius (talk) 14:03, 20 February 2015 (UTC)
I have used language of work or name (P407) a lot on WikiNews items. Several of them had multiple languages attached. I would therefor keep it. Edoderoo (talk) 22:19, 22 March 2015 (UTC)
@Infovarius: What is the problem if we merge both properties into "language" ?Snipre (talk) 13:05, 23 March 2015 (UTC)

@Edoderoo: Can you provide an example please ? And if the new property is called "language", is it still a problem ? Snipre (talk) 13:05, 23 March 2015 (UTC)
- @Snipre:, find an example here: Netanyahu's Likud party wins election in Israel (Q19618665). 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)
@Edoderoo: How can you use a language property for a wikinews article ? As I see there is a French corresponding article so why English and not French ? Snipre (talk) 16:26, 27 March 2015 (UTC)
Because English *and* French. I'm Dutch, so for me the English and the French go perfectly together on the same property without any issue ;-) Edoderoo (talk) 22:07, 27 March 2015 (UTC)

A wikinews can be in language "A" about some public speech which was performed in another language "B". I suppose we can point both languages with different properties (language of work or name (P407) for A, original language of film or TV show (P364) for B). --Infovarius (talk) 08:36, 2 April 2015 (UTC)
@Edoderoo, Infovarius: You mix different concept: the language of the wikinews and the language of the object of the wikinews article. For the first language, this is redundant with the sitelink information. If you want a French article you filter the sitelinks and select the ones which are in French. The example you gave was an typical example of the problem of redundancy: the language properties were not updated according to the sitelinks. And this organization is not applied in the others items: the language property is never used to describe the language of the WPs connected to the item. Look at apple (Q89): 153 sitelinks and around the same number of different languages. But no use of language of work or name (P407) or original language of film or TV show (P364). So why do we have to have another practice for wikinews articles ?

Then about the language of the object of the article. Here we have a problem of definition: Is the item about the wikinews article or about the object of the article ? The classification of the item is clear in your example: instance of Wikinews article. So the language of the object in not part of this item. You should use 2015 Israeli legislative election (Q17012412) to define the language of the object of the article, and how can an election have a language property ? Here we have a confusion based on the relation "the election is in Israel", "Hebrew is speaking in Israel" so "language of election is Hebrew". Snipre (talk) 14:31, 7 April 2015 (UTC)
@Snipre: Which "language property of the work item" are you referring to? As far as I can tell, it's possible to create an item without any language property except for language of work or name (P407) unless someone uses title (P1476) and signifies the language. There are occasionally works that have titles in more than one language, despite the text only being in one, so going by the title language doesn't make sense to me. The way the descriptions are written, I've always used original language of film or TV show (P364) as the language of the first edition, not necessarily the current translation. To me, that's been language of work or name (P407). Hazmat2 (talk) 15:42, 27 April 2015 (UTC)
The idea is to have one language property called "Language" and to use this property for work AND editions items. The use of the merged property "Language" can be used to retrieve all works in a defined language as well to define the language of the editions in the original language or the language of the translated editions. No need any more of a original language property for work and another property for the editions items. We can't use the language of the title because the language of the title can be different from the language of the work/edition. --Snipre (talk) 16:05, 10 May 2015 (UTC)

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

Support merging two properties (original language of film or TV show (P364) and language of work or name (P407)) into one. Target name shall be "Language". -- Vlsergey (talk) 11:41, 20 May 2015 (UTC)
@Hazmat2, Infovarius, Edoderoo, Giftzwerg 88, Visite fortuitement prolongée: and @Danrok, Kolja21, Wikijunkie, Nightwish62: I modified a little the description text of the proposed action:

The proposed action is to merge original language of film or TV show (P364) and language of work or name (P407) in one property "Language" which can be used for all cases where an item or a statement has to be defined according to its language. This can be for work, but for name or other kind of items.

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

If original language of film or TV show (P364) and language of work or name (P407) will be merged, then how to handle in a case when the original text is unknown, but we know the original language? -- Sergey kudryavtsev (talk) 10:02, 27 May 2015 (UTC)
@Sergey kudryavtsev: Please provide an example. I don't understand the problem. Snipre (talk) 10:44, 27 May 2015 (UTC)
The example: s:ru:Я целый день изнемогаю (Гейне/Фет) — we know the translator — Afanasy Fet (Q314212), the author — Heinrich Heine (Q44403) and the original language — German (Q188), but we don't known the original text. -- Sergey kudryavtsev (talk) 11:30, 27 May 2015 (UTC)

@Snipre: What you say about this example? -- Sergey kudryavtsev (talk) 03:55, 4 June 2015 (UTC)
@Sergey kudryavtsev: The rule is for translation to have a different item. So in your case you should create an item for the original text and a second one for the translation. We don't care about the original text because we use concept in WD. So in the item of the original text we use "language": german and in the second "language": russian. Snipre (talk) 08:07, 4 June 2015 (UTC)
The way, which you recommend, is very unnatural. In fact you suggest to describe in wikidata the hypothetical, irreal things. -- Sergey kudryavtsev (talk) 10:28, 4 June 2015 (UTC)
Does your original exist or not ? If you have proof that a translation was made (like a reference) so you can't say that the text was hypothetical or non real. In summary if you have enough sources to say that the author was Heinrich Heine (Q44403) and that the original language was German to put that information (all information should normally have sources in WD) in the item of the translated text, you have enough proofs to be able to create an item for the original text. Snipre (talk) 20:29, 4 June 2015 (UTC)
Does your original exist or not ? — we don't know this until the original will be found. The text in the books has a subttle "From Heine", but not say which exactly. The subtitle may be true or false — we don't know. E.g. this poem by Dmitry Minaev (Q4293952) has a subttle "Изъ T. Мура." ("From T. Moore" in English). In fact this isn't a translation from Thomas Moore (Q315346), but the original poem! Minaev put this subttle to easyly pass the censura barriers in the Russia:

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

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

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

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

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

Sorry I wasn't accurate when I was asking if the original text. WD like WP don't need to have a proof of existence to create an item or an article, they just need to have a document with some authority saying that was true (or not) and then you create your item based on that source and you cite the source in the different statements.
If you have a document X saying that text Y is a translation of text Z and that the original language was OL with the author AA and the translation was done by TT in language TL, you can create three items:
- item about document X
  - 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)
Oppose There can be situations when 1 property can be not enough. I can not find convincing example, but here is another one. A film (for example, animated) can be in language A originally (original language of film or TV show (P364)), but voice actor (P725) can provide different backgroud languages (so language of work or name (P407) can be used as qualifier for them). --Infovarius (talk) 10:21, 27 May 2015 (UTC)
Already treated: in the data structure of WD your scenario is described by two items: one for the original movie with the main voices and then a second item for the second language with another set of voices. You can't mix now all voices for different languages in one item. The only open question is about subtitled versions. But you can perhaps show the problem using this item Shrek the Third (Q486588). Snipre (talk) 10:35, 27 May 2015 (UTC)

Keep the both properties. Instead of deleting, we should impose the rule about language of work or name (P407) and original language of film or TV show (P364): either only language of work or name (P407) (for the original works) or both (for the translated/dubbed works). -- Sergey kudryavtsev (talk) 10:28, 4 June 2015 (UTC)
Delete Merge the two properties. Per Snipre. --Casper Tinan (talk) 11:43, 4 June 2015 (UTC)
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)
Keep both properties. It's easier to have a separate property than a property plus a qualifier for the main use case. --- Jura 17:10, 26 June 2015 (UTC)
@Jura1: Sorry but I don't see where you find the mention of a qualifier: we don't need a qualifier because according to the general structure for works in WD you create different items for the different versions of a work. And when you need the language of the original version you use the data of the item of the work and not the items of the versions. Snipre (talk) 12:36, 1 July 2015 (UTC)
I don't see people creating items for each synchronized version of a film. Original language is sufficient as a property for these (P364). Add additional languages with the other property if you must. It would be a horrible mess if we would create multiple items for the same film or tv series. --- Jura 12:42, 1 July 2015 (UTC)
@Jura1: You don't see people creating items for synchronized versions because they aren't trained to do it. But now the question it to now for which purpose you want to add language of work or name (P407) in an item of a movie ? Just to say that a movie exists in a certain language ? What's about the publication or release date of the synchronized versions ? What's about the name of the voices in the translated versions ? Just think about anime movies where for each language and for each character you have a different person. "It would be a horrible mess if we would create multiple items for the same film or tv series." That's what we are doing for books and this was never a problem. Snipre (talk) 15:29, 15 July 2015 (UTC)

@Snipre: It's not as simple as training people to create multiple items for a film. The size of that task is very large, there are nowhere near enough contributors. Consider Star Wars, for example: [[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)

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

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

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

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

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

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

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

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

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

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)

Delete I've been thinking about this issue for a while. Let me give an example:

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

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

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

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

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)

Keep The two properties can sometimes be a mess, but, e.g., for Stille Nacht Heilige Nacht (Q172152) it makes sense to me. The original language of film or TV show (P364) is German (Q188) while it exists in a number of other languages. Splitting the item into translated versions seems to babelfuscate language links? — Finn Årup Nielsen (fnielsen) (talk) 19:45, 22 January 2016 (UTC)
- You have 2 values for lyricist (P676), 6 for performer (P175) (with missing qualifiers), 5 for MusicBrainz work ID (P435) (with missing qualifiers again!), 4 for title (P1476), 4 for language of work or name (P407), 3 for audio (P51)... 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)

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

Delete language of work or name (P407) in favor of P2439 (P2439), Neutral on original language of film or TV show (P364) --Srittau (talk) 16:00, 16 April 2016 (UTC)
- And a procedural note: Since this deletion request was started, P2439 (P2439) 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)
Delete - merge these two --Lingveno (talk) 11:23, 26 May 2016 (UTC)
@Lymantria: Can you close this RfD ? Change lead to reformulate the deletion request. Snipre (talk) 00:37, 7 June 2016 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

manufacturer (P176) and main building contractor (P193)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Not deleted - consensus to keep. --Lymantria (talk) 05:24, 1 June 2016 (UTC)

manufacturer (P176) manufacturer (P176): (delete | history | links | entity usage | logs | discussion)
main building contractor (P193) main building contractor (P193): (delete | history | links | entity usage | logs | discussion)

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

very weak keep. I believe that these are representing separate concepts, but I'm having a hard time trying to put this feeling into words (which is why the "very weak"). I'll keep thinking though. Thryduulf (talk: local | en.wp | en.wikt) 14:29, 10 May 2016 (UTC)
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 Keep as well. Sub-property that implies a few things that manufacturer (P176) does not imply. --Srittau (talk) 15:39, 17 May 2016 (UTC)
Keep Agree with Srittau. Technically it would work to handle main building contractor (P193) as a manufacturer (P176), if construction works like any other manufacturing, but I do not think that is the case. -- Innocent bystander (talk) 06:20, 18 May 2016 (UTC)
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)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P1658 (number of faces)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Deleted - consensus to delete. --Lymantria (talk) 08:49, 1 June 2016 (UTC)

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

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

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

- Hi guys; has part Search or has part(s) of the class (P2670) ? 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)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Freebase ID (P646)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Not deleted - consensus to keep. --Lymantria (talk) 05:22, 1 June 2016 (UTC)

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

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

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P1244 (phone number (URL))

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Deleted - consensus to delete. --Lymantria (talk) 05:18, 1 June 2016 (UTC)

P1244 (P1244): (delete | history | links | entity usage | logs)

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

Oppose. In the meantime URL with tel: can be implemented. So the announced use of that should be honored. phone number (P1329) should be deleted instead.
--- Jura 15:15, 23 May 2016 (UTC)
- Delete seems like P1329 can be made to work better
  --- Jura 15:51, 24 May 2016 (UTC)
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)
Support deletion. @Nikki, Pigsonthewing: from the PC discussion. --Izno (talk) 09:16, 24 May 2016 (UTC)
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)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

phone number (P1329)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Not deleted - consensus to keep. --Lymantria (talk) 05:17, 1 June 2016 (UTC)

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

How would using an URL fix the malformed inputs? There is nothing preventing you from entering URLs that don't conform to the format prescribed by tel:. --Srittau (talk) 15:27, 23 May 2016 (UTC)
Also Oppose, phone number (P1329) has clearly won the popularity contest and is the better property, since representing phone numbers as URLs adds an unnecessary level of abstraction. --Srittau (talk) 15:29, 23 May 2016 (UTC)
Use of P1244 (P1244) was always planned, but is currently not possible. It can now be activated and Lydia asked for community feedback before. URLs have formatting constraints built in while strings don't.
--- Jura 15:39, 23 May 2016 (UTC)
- Telephone numbers are not URLs. No need to "activate" an inferior property when we already have a superior one. Especially when tel: URLs are not supported yet and supporting them would require valuable developer resources. --Srittau (talk) 15:49, 23 May 2016 (UTC)
  - It's an accepted prefix. It wont make them http-urls obviously and the change needed has been identified and is fairly trivial. I noticed you didn't respond when being asked for help to find a solution to clean-up Wikidata:Database_reports/Constraint_violations/P1329#.22Format.22_violations in the project chat discussion: Wikidata:Project_chat#phone_number_.28URL.29_.28P1244.29_and_phone_number_.28P1329.29.
    --- Jura 15:55, 23 May 2016 (UTC)
    - Because all violations have been fixed in the meantime. --Srittau (talk) 16:01, 23 May 2016 (UTC)
      - Thanks for doing that. I had cleaned up some entries before and was looking for a solution to prevent malformed entries. The problem is that given the few entries that use the property, the ratio of problematic entries is -IMHO- too high. If we don't want to keep cleaning them up, we need to find a solution that prevents problems beforehand. P1244 is such an option.
        --- Jura 16:15, 23 May 2016 (UTC)
- What formatting constraints built in do you think exist, and have you confirmed that with the tech team? I don't believe that what you are saying is true.
  That aside, what are your primary constraints concerns? --Izno (talk) 09:19, 24 May 2016 (UTC)
  - Good point. Seems like anything like [[5]] would work. 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)
Oppose deletion. @Nikki, Pigsonthewing: from the PC discussion. --Izno (talk) 09:16, 24 May 2016 (UTC)
Keep As per project chat discussion. - Nikki (talk) 09:36, 24 May 2016 (UTC)
What is (an example of) a malformed phone number (P1329)? 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)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Lake ID (Sweden) (P761)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Not deleted withdrauwn

Superseded by more generic EU Surface Water Body Code (P2856). All strings in Lake ID (Sweden) (P761) are valid in EU Surface Water Body Code (P2856) when preceded by "SE".--Lymantria (talk) 08:57, 26 May 2016 (UTC)

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

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

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

Stöder 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 Lake ID (Sweden) (P761) cannot be superseded entirely by EU Surface Water Body Code (P2856). Lymantria (talk) 05:40, 3 June 2016 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

cites work (P2860)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Not deleted Consensus to keep.

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

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)

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)

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

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)

Keep as I would

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

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)

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)

@Egon Willighagen: there is no standard policy for inverses - in some cases the "active" property is used (e.g. product, material, or service produced or provided (P1056)), in some the "passive" (e.g. investigated by (P1840)) and in others we have both (e.g. has immediate cause (P1478) and immediate cause of (P1536)), 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)

@Thryduulf: 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)

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. Wikipedia:There is no deadline (Q13599626). --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)

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)

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)

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 Project:Brigading (Q13365390) 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)

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)

@Wittylama: 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)

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

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)

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)

@Aubrey: 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)

@Thryduulf: 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)

@Aubery: 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)

Keep! -- Innocent bystander (talk) 09:28, 27 May 2016 (UTC)

@Innocent bystander: 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)

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)
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)
- @Tobias1984: 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)
- @Tobias1984: 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)

@Srittau: 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)

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)

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)
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 @Daniel Kinzler (WMDE):, 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)
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)
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 Support 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)

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)
(edit conflict) 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)
@Dancter: 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)
rhetorical question (Q316694). Common sense is not creating a property without consultation of people outside your own filter bubble (Q1415581) (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)

(edit conflict)Common 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)

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

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P2890

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Speedy deleted -- unintentionally created with wrong datatype. Lymantria (talk) 19:32, 6 June 2016 (UTC)

P2890 (P2890): (delete | history | links | entity usage | logs) Created as wrong datatype. Correct property is UMLS CUI (P2892). --Izno (talk) 17:32, 6 June 2016 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P999

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Speedy kept, proposal discussion found, and now also in use. -- Innocent bystander (talk) 11:10, 8 June 2016 (UTC)

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

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)
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)
Keep This is one of the parameters of Template:Starbox reference (Q11010269) 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)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P2901

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Speedy deleted, accidental creation with wrong datatype. Lymantria (talk) 08:35, 13 June 2016 (UTC)

P2901 (P2901): (delete | history | links | entity usage | logs)

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)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

property usage tracking category (P2875)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Consensus to keep --Lymantria (talk) 07:14, 17 July 2016 (UTC)

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)

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 criterion used (P1013) with some criteria items to indicate different types of tracking subcategories here? Lymantria (talk) 11:11, 30 May 2016 (UTC)
- Hence 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 > 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 Wikipedia:Do not disrupt Wikipedia to illustrate a point (Q4657775) 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)
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 topic's main category (P910) we had previously to property usage tracking category (P2875). In that case, we should keep this.
  --- Jura 09:05, 11 June 2016 (UTC)
  - Keep --Mr. Ibrahem (talk) 19:56, 11 June 2016 (UTC)
Keep IMO useful metadata. Matěj Suchánek (talk) 17:11, 25 June 2016 (UTC)
Keep. And Jura, stop making disruptive deletion requests. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:15, 7 July 2016 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P2932, Property:P2933, Property:P2934

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

Delete No discussion and no explanation about the use of these properties. Snipre (talk) 18:33, 23 June 2016 (UTC)
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

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Withdrawn.--GZWDer (talk) 16:18, 3 August 2016 (UTC)

Propose to merge with place served by transport hub (P931) and rename it to "places served". GZWDer (talk) 20:41, 2 August 2016 (UTC)

Oppose This was suggested and rejected when operating area (P2541) was proposed. If it is merged "places served" is not a good label as P2541 includes areas that are not "served" - e.g. Rail Accident Investigation Branch (Q7283877) does not "serve" Channel Tunnel (Q10257) rather it is jointly responsible for investigating accidents that occur there, and World Association of Zoos and Aquariums (Q60427) doesn't serve world (Q16502) rather it is an umbrella organisation that supports its members wherever they are in the world. Thryduulf (talk) 00:29, 3 August 2016 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P3062

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Speedy deleted, wrong datatype. 07:17, 4 September 2016 (UTC) (done a lot earlier)

P3062 (P3062): (delete | history | links | entity usage | logs)

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

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P2608 (P2608)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Consensus to Delete, since P2608 (P2608) is a duplicate of IGPCV ID (P2473).--Fralambert (talk) 02:50, 28 August 2016 (UTC)

P2608 (P2608): (delete | history | links | entity usage | logs)

The property Property:P2608 (Valencian Property of Local Relevance id) seems a duplicate of IGPCV ID (P2473), as both represent Property of Local Relevance (Q11910247). As IGPCV ID (P2473) is more complete, I've just substituted the only item using P2608 (P2608) (the property example Ermita de la Virgen de Avellá (Q11681547)) 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)

@Amadalvarez, KRLS: ping property proposers --Pasleim (talk) 08:35, 17 August 2016 (UTC)

Thanks, @Pasleim, Suruena:.--Amadalvarez (talk) 09:27, 17 August 2016 (UTC)

Support It's really the same. I've copied the "source" in the older's description page from the P2608 (P2608) 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)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P3247

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Speedy deleted. Lymantria (talk) 08:49, 4 October 2016 (UTC)

P3247 (P3247): (delete | history | links | entity usage | logs)

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

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

uses property (P3176)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

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)

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)

@Lymantria: --ValterVB (talk) 17:25, 22 September 2016 (UTC)

Keep Disagree with Andy's conclusion about missing consensus. Furthermore I consider the property useful. Lymantria (talk) 21:24, 22 September 2016 (UTC)
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. Monitoring the Gender Gap with Wikidata Human Gender Indicators (Q26955946) it's clear that main subject (P921) 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)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

original language of film or TV show (P364)

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

There is already a section for this above.
--- Jura 02:27, 7 June 2016 (UTC)

original language of film or TV show (P364): (delete | history | links | entity usage | logs | discussion) Currently we have 3 properties to describe languages of an item (language of work or name (P407), P2439 (P2439) and original language of film or TV show (P364)). This discussion aims to delete original language of film or TV show (P364) in favour of an unique property for language P2439 (P2439).

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)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

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

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:44, 21 November 2016 (UTC)

P1223 (P1223), P1224 (P1224), P1226 (P1226) and P1231 (P1231)

These ID's are essentially the same, as all links created redirect into https://catalog.archives.gov/id/$1. U.S. National Archives Identifier (P1225) 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)

Support the merge. --Fralambert (talk) 20:59, 3 September 2016 (UTC)
Support merge. --Pasleim (talk) 22:11, 3 September 2016 (UTC)
Support If the formatter URL is indeed the same for all, then I agree on merging them. Mbch331 (talk) 09:05, 4 September 2016 (UTC)
Support merge.--Jklamo (talk) 20:13, 18 September 2016 (UTC)
@Lymantria: 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)
- @Multichill: 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 P1222 (P1222) to U.S. National Archives Identifier (P1225). Multichill (talk) 15:20, 7 October 2016 (UTC)
    @Multichill: can you please label the deleted properties? Thanks. — billinghurst sDrewth 06:55, 5 November 2016 (UTC)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:43, 21 November 2016 (UTC)

P3164 (P3164)

P3164 (P3164): (delete | history | links | entity usage | logs)

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)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:46, 21 November 2016 (UTC)

Property:P3244

P3244 (P3244): (delete | history | links | entity usage | logs)

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)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:39, 21 November 2016 (UTC)

BBC News Democracy Live ID (P2173)

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)

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:38, 21 November 2016 (UTC)

Property:P3287

P3287 (P3287): (delete | history | links | entity usage | logs)

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

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

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:43, 21 November 2016 (UTC)

Property:P3312

P3312 (P3312): (delete | history | links | entity usage | logs)

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

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:42, 21 November 2016 (UTC)

Property:P3313

P3313 (P3313): (delete | history | links | entity usage | logs)

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

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:41, 21 November 2016 (UTC)

P3319 (P3319)

P3319 (P3319): (delete | history | links | entity usage | logs)

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

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:40, 21 November 2016 (UTC)

Property:P3317

P3317 (P3317): (delete | history | links | entity usage | logs)

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

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:39, 21 November 2016 (UTC)

P3369 (P3369)

P3369 (P3369): (delete | history | links | entity usage | logs)

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

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

circle of (P1776)

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

Keep it is used as qualifier on creator (P170)=anonymous (Q4233718) [9]. --Pasleim (talk) 12:58, 25 November 2016 (UTC)

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

I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. --ValterVB (talk) 16:37, 25 November 2016 (UTC)

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

point of penalty (P2955)

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 Marfi 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)
Oppose. 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)
@Tubezlob: 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)
Oppose 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: UEFA Euro 2016 qualifying Group H (Q15807025) and UEFA Euro 2016 qualifying Group I (Q15807032). 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)

P3384 (P3384)

P3384 (P3384): (delete | history | links | entity usage | logs)

Duplicate of BLDAM object ID (P2081), now unused.--Fralambert (talk) 02:18, 4 December 2016 (UTC)

@Oursana: 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)

@Jura1: 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)

Wikidata:Properties for deletion/Archive/2016

Language of Instruction / Medium of instruction

after a work by (P1877) etc.

Wikidata example properties

language of work or name (P407) and original language of film or TV show (P364)

manufacturer (P176) and main building contractor (P193)

Property:P1658 (number of faces)

Property:P1244 (phone number (URL))

Property:P2932, Property:P2933, Property:P2934

P1223 (P1223), P1224 (P1224), P1226 (P1226) and P1231 (P1231)

Navigation menu

Search