Wikidata:Properties for deletion

From Wikidata
Jump to: navigation, search
Shortcut: WD:PFD

This is the properties for deletions page. To nominate a property for deletion, complete the following steps:

  • Place the {{Property for deletion}} template on the property talk page.
  • Open the discussion on this page under the "Requests" section below.
  • Notify the user who originally proposed the property and the property creator for it on their respective talk pages.
  • Validate the property isn't being used in other projects (using Template:ExternalUse) and if it is leave a message in Village pump of the project project

Requests may be closed after 7 days, but may be extended if consensus is not reached. If the request is uncontroversial, for example "accidentally created with wrong datatype", please use the faster-moving requests for deletions instead.

Add a new request

On this page, old requests are archived. An overview of all archives can be found at this page's archive index. The current archive is located at Properties/1.





for permissions

for deletions

for deletion

for comment



Please add a new request at the bottom of this section, using {{subst:Rfd|1=pagename|2=reason for deletion}}.

type of administrative territorial entity (P132)[edit]

(delete | history | links | logs | discussion) Dexbot is duplicating it to instance of (P31). Therefore we can delete this property.--GZWDer (talk) 11:20, 7 December 2013 (UTC)

  • Symbol keep vote.svg Keep for a municipality instance of (P31) can have dozens of values like Hanseatic city (Q707813), city with tens of thousands of inhabitants (Q896881), municipality of Germany (Q262166), college town (Q1187811), district capital (Q134626) etc, but Property:P132 should only have the type of administrative division which is used for infoboxes and other classification templates. Holger1959 (talk) 02:28, 8 December 2013 (UTC)
    • Holger1959 That is not a reason for keep. It is no problem that something can be an instance of more classes. What is your real problem? College town or Hanseatic city are not administative units, are they? Municipality of Germany is one. If one is interested in administration one simply looks a the classes that are subclasses of administrative unit. There is no "type of collegeness" either, that would return whether something has a lot of college population. Androoox (talk) 14:20, 16 January 2014 (UTC)
  • Symbol keep vote.svg KeepPictogram voting comment.svg Comment the organization of administrative divisions was the first big discussion in Wikidata and, imho, changes cannot be discussed only here. Why we cannot use more than one ontology? We can use part of (P361) instead of instance of (P31) for example. @GZWDer: could you give an example of hierarchy using P31/P279 in this case? --Paperoastro (talk) 10:51, 8 December 2013 (UTC)
    Therefore we can use instance of (P31)=(a new item named "type of administrative division"). I made this rfd because Izno said (Dexbot's duplicating) would help us delete P132 if all P132 is copied to P31.--GZWDer (talk) 10:58, 8 December 2013 (UTC)
    Could be interesting. I saw now the discussion you linked (thanks!). For me it is not a simple question, so I prefer to wait for queries. --Paperoastro (talk) 11:35, 8 December 2013 (UTC)
  • Symbol keep vote.svg Keep Putting everything in P31 means that one has first to follow up the P279-tree until one gets the full information. A bot can do it fast but a human unser...? --Pasleim (talk) 11:40, 8 December 2013 (UTC)
    That's true of P132 also. --Izno (talk) 16:33, 8 December 2013 (UTC)
    Pictogram voting comment.svg Comment I don't understand which information a human would get with this property you would'nt get with P31 immediately... Could you give an example ? TomT0m (talk) 16:48, 9 December 2013 (UTC)
    Well, would you directly know if a "School district in Sweden" is an administrative unit or not? -- Lavallen (talk) 08:51, 10 December 2013 (UTC)
    The answer is no, it's a way to organize the Human resources in the schools of a municipality. -- Lavallen (talk) 10:07, 10 December 2013 (UTC)
  • Pictogram voting comment.svg Comment My gut instinct was to delete because it seemed to be used in the exact same way as "instance of". But Holger1959 makes a very interesting point that makes me wonder about all properties. If many properties are merged into "instance of", how will infoboxes and other tools using the data know that an item's defining type is, for example, "municipality of Germany" rather than a secondary type like "college town"? I assume someone already has a solution for infoboxes, but I'd like to hear it before voting on any more properties. --Arctic.gnome (talk) 05:49, 10 December 2013 (UTC)
    I suppose it is possible to do but there's another point by Holger1959. Each specific property can have constraint "unique value" but combined "instance of" can't have such constraint which is inconvenient for validation tracking. --Infovarius (talk) 09:40, 10 December 2013 (UTC)
    Unique value amongs a class that is an instance of <administrative division type> would work. TomT0m (talk) 18:57, 10 December 2013 (UTC)
    It looks like the ranking system has just been added today, so that solves one problem. So, if we were to keep this, what would we do to make it worth duplicating the info in "instance of". I gather we'll use property constraints to limit what kind of data can go here? --Arctic.gnome (talk) 20:30, 10 December 2013 (UTC)
  • Symbol keep vote.svg Keep mass deletion requests without considering the severe consequences as outlined by Holger (mixing with other classifications) and Infovarius (constraint checking). Please provide a fully working alternative tooling first before claiming that everything can be done with P31.  — Felix Reimann (talk) 14:02, 10 December 2013 (UTC)

  • Symbol delete vote.svg Delete. There should be one -- and preferably only one -- obvious way to specify the type of an instance. The arguments above for keeping this property are founded upon very flawed ideas about constraints, as well as P31 antipatterns endemic among the administrative subdivisions community. I explain those issues and point out solutions where helpful below.
Items about administrative subdivisions tend to show a basic P31 abuse: using 'instance of' as a catch-all property to shoehorn in statements that belong in conventional properties (or don't belong at all). Let's consider an example:
Aalen (Q3951)
type of administrative territorial entity (P132) municipality of Germany (Q262166)
instance of (P31) Grosse Kreisstadt (Q448801), city (Q515), district capital (Q134626), mittelzentrum (Q1401585), spa town (Q4946461), Free imperial city (Q57318)
The fact that there are 6 'instance of' values for Aalen is a bad smell. To start, Free imperial city (Q57318) and Grosse Kreisstadt (Q448801) are subclasses of city (Q515), so the claim Aalen (Q3951) instance of (P31) city (Q515) is redundant and should be removed. The district capital (Q134626) P31 value should be moved to a new property 'capital of' (inverse of capital (P36)). The other Aalen P31 values should likely be moved to other conventional properties. From what I can tell, Free imperial city (Q57318) is an obsolete, historical classification, and thus should have 'start' and 'end' dates indicating such. spa town (Q4946461) should be moved to an appropriate property for tourist marketing information -- having it in 'instance of' is also problematic because it's a subclass of 'town', which is conventionally disjoint with 'city'. Grosse Kreisstadt (Q448801) seems like the most appropriate P31 value, since it's a subclass of municipality of Germany (Q262166).
In other words, the example from Holger1959 that several have noted as a reason to keep P132 is precisely how we should not be using P31. The claim 'instance of (P31) city with tens of thousands of inhabitants (Q896881)' that Holger cites is an example of the poorly-designed type we get with that approach. (To be clear: this claim should be removed and, once the quantity datatype is available, replaced with a 'population' property claim.) Having types like 'city with tens of thousands of inhabitants' is poor practice because it is elevating a trivial query result set into a class. Classes should entail larger batches of statements about a subclass or instance, and not merely one value of one very dynamic property that will obsolesced the moment queries are available.
instance of (P31) should generally have one value, not many values as often seen in items maintained by the country subdivisions task force. In rare cases with multiple P31 values, one should be usually be preferred -- the classification that's most current, most widely used in the most reliable sources. P31 is for defining an instance's type; it is not a catch-all property to throw in any plausible statement under the sun that makes sense when connected with the phrase "is a". instance of (P31) is a fundamental tool to develop structured data, not a way to stuff NLP fodder into Wikidata.
The fact that entities can theoretically be classified along many axes is not a good argument to eschew generic type properties like 'instance of' in favor of domain-specific type properties like 'type of administrative division'. The same argument applies equally to domain-specific type properties. The only thing that makes P31 different than P132 is that the country subdivisions task force has put together a well-defined taxonomy (along certain axes) for P132. Nothing significant prevents them from doing the same with P31. As I've demonstrated above, the way they're using P31 right now is an antipattern. They've essentially discarded P31 and are now use P132 the way P31 should be used.
Infovarius says that P132 has useful 'unique value' (i.e. 'one of') constraint checks. It doesn't -- 'one of' constraints are actually horrible for P132. Check out the top of the P132 talk page and you'll see why -- over 300 'one of' constraints, one for each (direct or derived) subclass of 'administrative subdivision '. 'One of' constraints are designed for properties with a small number of possible values, e.g. a 'sex' property having 'one of' constraints 'male', 'female', 'intersex'. Having 300 'one of' constraints is a severe antipattern. If you think it's bad now, wait until type of administrative territorial entity (P132) starts covering larger swaths of the world's administrative subdivisions. 300 will be a drop in the bucket. The current approach of using 'one of' constraints for P132 is difficult to maintain and unscalable.
Like having 6 'instance of' values is a bad code smell, so is having 300 'one of' constraints for a property. What this property is trying to do is ensure that the values of type of administrative territorial entity (P132) fulfill the statement 'subclass of administrative subdivision'. There's a better way to do that: use to replace the 300+ 'one of' constraints with 1 simple range constraint: subclass of (P279) administrative territorial entity (Q56061).
That doesn't actually do much, though. It simply tells us whether the value of P132 is a subclass of administrative subdivision, which is pretty vacuous. It ignores the basic question of why we need that constraint. What good does it do, exactly, for this 'type of administrative division' property? Even ignoring my argument above that 'instance of' should have one (or at least one preferred) value, each value in the P31 hydra seen in Aalen (Q3951) traces back up to subclass of (P279) administrative territorial entity (Q56061). So if we accept the idea that new, better tools enable sane constraints as I argue in the previous paragraph, then P132 offers nothing more than P31. Like the P132 value for Aalen, all the P31 values for that item trace back to the claim subclass of (P279) administrative territorial entity (Q56061). If a P31 value that violates that claim is added to instance of administrative subdivision, tools like Wikidata Generic Tree and WikidataQuery should be able to detect that.
In summary, I've shown that P31 is widely misused in items about administrative subdivisions, and that this antipattern can be fixed by essentially using P31 as it is designed to be used -- i.e. by using P31 as P132 is used now. Also, I've shown major flaws in the idea that P132 is necessary to maintain useful constraints on items about administrative subdivisions. That in turn shows how P132 is redundant with P31. There should be one -- and preferably only one -- obvious way to specify the type of an instance. We should delete this property. Emw (talk) 04:53, 11 December 2013 (UTC)
I have also seen a misuse of P31 in many items I have in my watchlist. The most common, is the use of P31:city and P31:town without any real source. -- Lavallen (talk) 07:55, 11 December 2013 (UTC)
Why do you weaken the broad usability of instance of (P31)? Of course, New York City is instance of global city, port city, metropolis, cities in New York, former capitals of the United States, and former United States state capitals... Wow! All this could be expressed with P31 and again all these classes are possibly part of their own hierarchy (for example, "former capitals of the United States" might be subclass of "cities of the US"). However, for a strictly regulated hierarchy, let us stick on specific subproperties of P31. This makes modeling, validation, and usage much more easier.
To your examples:
  • Aalen is instance of mittelzentrum (Q1401585). This cannot be deduced from the population size as this is a term from the German (no label) (Q15077398). No way to deduce this, but can be perfectly modelled with P31.
  • Aalen is instance of spa town (Q4946461). Why should we introduce new properties for this? Again, this can be perfectly modeled with P31.
  • Aalen could additionally be instanceof Michoacán (Q79861), river.
all these are valid uses of instanceof. So it makes it just simpler to use for the highly regulated hierarchy specific properties. Of course, we will tag P132 a subproperty of P31 as soon as Wikibase allows this. Just wait until this is possible. In the meantime, we should let the people from Wikidata:Country_subdivision_task_force do their great work in creating a consistent hierarchy. And no - there are no better tools for P31 out there.  — Felix Reimann (talk) 08:03, 12 December 2013 (UTC)
Instead of "instance of former United States state capitals" you should add "instance of capital of United States end date 1XXX-XX-XX".
I agree that the population sometimes can be difficult to identify. Stockholm (Q1754) for example, is not a well-defined entity. It is an informal entity, it has therefor no formal borders and the population can therefor not be accuratly specified. There is other items for the urban area of Stockholm, the municipality of Stockholm, the city of Stockholm and the metropolitan area of Stockholm, but Q1754 is neither of this. -- Lavallen (talk) 08:38, 12 December 2013 (UTC)
I updated some quantifiers in the Aalen (Q3951); improvements are almost always possible, cf. Special:Random. Let me respond to some of @Emw:'s statements:
  • "city (Q515) is redundant and should be removed" Aalen is a city (Q515) since 1339, long before it was a Grosse Kreisstadt (Q448801) or Free imperial city (Q57318). By replacing the statement, you will lose this information. Also I suggested on several discussions that maybe the object town with town rights and privileges (Q13539802) could be used instead.
  • "spa town (Q4946461) should be moved to an appropriate property for tourist marketing information" Well, I could think about a property like 'touristic type', but do you not want to delete exactly such type-property?
  • "[...]class of 'town', which is conventionally disjoint with 'city'" I doubted that these two classes are always disjoint.
  • Please note that city with tens of thousands of inhabitants (Q896881) and mittelzentrum (Q1401585) is not the same.
  • Logical entailment is a nice idea, but as far as I know it is not (yet) implemented in Wikidata.
  • "instance of (P31) should generally have one value, not many values" Why do you think so? I agree that extreme tagging as you mentioned above is not good. But for example it is quite common in the semantic web to add some more rdf:type properties in order to use the comination of several vocabularies. Moreover, if you for example compare with dbpedia: they have 6 (different) values connected by rdf:typeof.
I think it might be a good idea to discuss some reorganization with administrative objects as well as to push the implementation of more and better tools dealing also with quantifiers etc. --Zuphilip (talk) 13:33, 13 December 2013 (UTC)
  • Symbol delete vote.svg Delete — @Emw: I agree. I'd much rather have the type of administrative division be the preferred or only P31 value of political divisions and move all their other P31 values to superclasses of those values (like "US state" under "federated state") or to another property (like "city with hundreds of thousands of people" as a population property). At Wikidata:Political geography task force I've been trying to find a way to organize the types of administrative divisions so that they can each have one P31 value and still be sorted into the right superclasses. --Arctic.gnome (talk) 05:29, 11 December 2013 (UTC)
  • Symbol delete vote.svg Delete for EmW. I'm totally agree with your considerations! Using P31 as you told, we can improve the hierarchy made with P132. --Paperoastro (talk) 21:22, 11 December 2013 (UTC)
  • Symbol delete vote.svg Delete, per EmW. instance of (P31) should be used instead. --Yair rand (talk) 09:52, 12 December 2013 (UTC)
  • I'd tend to vote delete but administrative divisions are often very tricky to deal with. Felix Reimann point has to be taken into consideration: we should have an idea on either how to say "is a spa town" without using p31 or, if we want to use p31 for that, how we can avoid having "spa town" showing up in infobox instead of the administrative status. I do not think that marking p132 as a subclass of p31 is a really good solution because what can be considered an administrative division is pretty fuzzy. An alternative solution would be smarter templates, but they may be rather heavy to manage, and that would require third-party users to have similarly sophisticated tools. Alternatively, we could rank the current administrative status as "preferred", but both "spa town" and former administrative status would be ranked as "normal", and that sounds a bit messy. Perhaps a p31 "legal status" subproperty could work but I am not sure. --Zolo (talk) 10:13, 12 December 2013 (UTC)
The problem with using ranks is that for the city infobox, of course the administrative status is preferred. However, for the "Spa infobox", instanceof "spa town deluxe" is of course the preferred one. I do not think that ranks work for this problem. We do not know in what our users are interested in. Nonetheless, ranks are great if you have two alternative values for the same specific statement, where one is the current or more valid claim; however, instanceof Spa town and instance of mittelzentrum (Q1401585), both are equally valid.
With smarter templates, we would move the handling of complexity to the users, which if interested in the administrative hierarchy would need to be aware that it might happen that there are cities which are also spa towns, port towns, ...  — Felix Reimann (talk) 11:14, 12 December 2013 (UTC)
  • Symbol delete vote.svg Delete I think all "(instance|type) of x properties" are redundant and should be merged with instance of (P31). --Jakob (Scream about the things I've broken) 13:52, 13 December 2013 (UTC)
  • Symbol delete vote.svg Delete Agree, all "(instance|type) of x properties" should be merged with instance of (P31). (But P31 could have many values in my opinion.) Michiel1972 (talk) 10:59, 17 December 2013 (UTC)
  • Side-Pictogram voting comment.svg Comment Regarding the remark "'town', which is conventionally disjoint with 'city'": note that in much of continental Europe, there is no division between towns and cities. This is an example of the difficulty of making a language-independent classification. Items like spa town (Q4946461) would probably better be a subclass of locality (human settlement) in general, not of town/city/village. Bever (talk) 01:03, 3 January 2014 (UTC)
    Yes. In English it is "by the letter" related to "town" and in Swedish it is related to "ort" (settlement/locality). This is one of the big challenges in this project. -- Lavallen (talk) 06:54, 3 January 2014 (UTC)
  • Symbol delete vote.svg Delete and replace with instance of (P31). — TintoMeches, 17:48, 6 January 2014 (UTC)
  • Symbol keep vote.svg Keep as there are IMO no acceptable outline of a migration/deletion process. I am not aggainst some reorganization, but here the question is only delete or not. --Zuphilip (talk) 17:36, 10 January 2014 (UTC)
    You're opposing for the reason that there is no "outline of a migration" process and yet you offer no outline of such a process. I'm puzzled. That aside, as part of the P107 removal I asked Amir to add P31 where P132 was used. For a substantial number of items, P132 could simply be removed at this time. For most or even all other uses of this property, it seems pretty clear to me that P132 could simply be replaced by P31. --Izno (talk) 16:01, 14 January 2014 (UTC)
    I see migration a little bit larger. Certainly, one question is with which property the old one should be replaced. The proposal was to take instance of (P31). But in the discussion above it become clear that this will not be the end. Let me cite Emw from above: "instance of (P31) should generally have one value, not many values as often seen in items maintained by the country subdivisions task force". Thus, it is really not clear how to replace the (multiple) type of administrative territorial entity (P132) statements on the same object. Another question is how can we manage the statement and for example enforce that the general object city (Q515) is not used as an administrative value. There are people who are working at the constraint violations, see . How would you migrate the constraints at Property talk:P132? How would you migrate constraints on other properties containing P132? I haven't read a word about that here. There is also a lot of work to be done on the ontology involving administrative units. And yes, I will help to reorganize stuff. But for the moment I guess it is easier to work in a seperate property. --Zuphilip (talk) 17:16, 14 January 2014 (UTC)
    I guess it is less of a problem to combine "city in U.S." with "spa town" or "town in U.S." with "county seat". I see no problems there. There are also for example some "county in New York state" who are "borough in New York city" at the same time, without any serious problems. Adding "population" and "area" to such items will give no big problems (as far as I know, I'm not an expert of the organisation of NY). But I see some cases where "city" and "island" are used in the same item. Since "population" and "area" most often isn't exactly the same for the island as for the city, we will have some serious problems in those cases. Is the area-property for the island or for the city? We can add qualifiers to solve it, but it would result in the Wikidata-version of Spaghetti code (Q1047561). -- Lavallen (talk) 19:47, 14 January 2014 (UTC)
  • Symbol keep vote.svg Keep until there is an acceptable migration path. -- 05:13, 14 January 2014 (UTC)
  • I now vote replace with instance of (P31). I have sometimes found it more or less difficult to find a good definition of what is an "administrative division". When the administrative function of a unit has been deprecated or when the administrative function is of less importance, I have seen it been questioned if P132 should be used. That is why I already now use P31 in Swedish urban areas. In the same way I guess you can ask yourself how much administration is today connected to Countys in some parts of New England. -- Lavallen (talk) 08:54, 14 January 2014 (UTC)
  • Symbol delete vote.svg Delete and replace with instance of (P31). Agree with Emw and the above of Lavallen. Whether a class is administrative or not can be defined on the class level. Androoox (talk) 16:18, 14 January 2014 (UTC)
  • Symbol keep vote.svg Keep. This property can be used to create a nice hierarchy of administrative divisions. I'm not clear how this can be done with P31. Many infoboxes want to know the administrative division where something is located. I'm not clear how this can be easily determined without this property. Keep and get the devs to create a 'Subproperty' property then declare this a subproperty of P31. Filceolaire (talk) 22:57, 14 January 2014 (UTC)
"a nice hierarchy of administrative divisions" would be nice to have. But ,when I edit about Sweden, I do not find any "nice hierarchy", I'm afraid. -- Lavallen (talk) 16:24, 16 January 2014 (UTC)
P31 is based on rdf:type, and subproperties of rdf:type are not valid in OWL DL. Thus, I think it would be a bad idea to create subproperties of P31. More: Wikidata:Project_chat#Subproperties_of_P31_not_valid_in_OWL-DL. Emw (talk) 23:56, 14 January 2014 (UTC)
That does not address the concern Filceolaire published. Androoox (talk) 14:12, 16 January 2014 (UTC)
@Filceolaire - As I wrote: "Whether a class is administrative or not can be defined on the class level.". If A is an instance of B and B is a subclass of "administrative unit", then the information is there to create a tree. If you don't understand it, please tell. Androoox (talk) 14:12, 16 January 2014 (UTC)
  • The hierarchy of administrative divisions are organized through subclass trees. The exact structure is being discussed at Wikidata talk:Country subdivision task force --Arctic.gnome (talk) 18:37, 23 January 2014 (UTC)
  • I think my comment as a delete should come as no surprise; I have—like Emw (maybe because of him? :)—systematically argued for deletion of type properties. The information of necessity can be and is captured through the use of instance of (P31). --Izno (talk) 01:30, 3 February 2014 (UTC)
    • My last comment to WD:PC#Population, maybe is an argument to split a lot of items about administrative entities. If it is done, I think there will be easier to make the merge of P132 and P31 possible. It demands us to use P31 with more care. -- Lavallen (talk) 08:27, 3 February 2014 (UTC)
  • Symbol keep vote.svg Keep:P31 is no alternative, following Pasleim and Holger--Oursana (talk) 08:43, 28 February 2014 (UTC)
  • Symbol keep vote.svg Keep P31 is (mis)used for a lot of claims causing that property field to be overpopulated. P132 offer a much more distinct and clear definition for administrative subdivisions. /ℇsquilo 17:47, 8 March 2014 (UTC)
  • I agree that the misuse of P31 is a BIG BIG problem. When I look around in some nations, I see that P31 already is used instead of P132. And I guess, that the rank-tool maybe can solve the problem with the misuse of P31? -- Lavallen (talk) 08:42, 10 March 2014 (UTC)
  • Symbol keep vote.svg Keep All discussion before show that we need to keep that property. --Dom (talk) 19:51, 15 March 2014 (UTC)
  • Symbol keep vote.svg Keep GerardM (talk) 07:27, 21 March 2014 (UTC)
  • Symbol delete vote.svg Delete, per Emw, me. For consistency in the datas mostly. TomT0m (talk) 14:14, 29 March 2014 (UTC)
  • Symbol delete vote.svg Delete because in my eyes it does not bring advantages over instance of (P31), it rather introduces new problems as stated above. Especially agree with User:Emw. Floscher (talk) 02:49, 30 March 2014 (UTC)
  • Symbol delete vote.svg Delete per Emw and Lavallen. Mushroom (talk) 09:32, 7 April 2014 (UTC)
  • Symbol keep vote.svg Keep Not everything can be done with P31. And we must have in mind that information should be easy to be reused. Looking up in the tree of P31 for which one is the administrative division, is really complicated and expensive. -geraki talk 19:57, 21 April 2014 (UTC)
    I'll ask details. We discussed a lot about that and we did not find anything that can't be done with instance of (P31). We even proposed mechanisms that will simplify the subclass tree, which would not be simpler with a dedicated property, by the way. TomT0m (talk) 20:07, 22 April 2014 (UTC)
  • Symbol keep vote.svg Keep makes the geographic structure easy to identify and maintain. ----- Jura 15:29, 10 May 2014 (UTC)

Dharma Drum Buddhist College place ID (P1188)[edit]

(delete | history | links | logs | discussion)

The only reason given for creating this property was: "spilted from above". "Above" meant Dharma Drum Buddhist College person ID (P1187). The DDBC (for persons) is used in zh:Template:Authority control so it's good to have this property even though it is used AFAIK only 1 time, see zh:Template:Authority control/DDBC. P1188 (for places) is used in zhWP: 0 times. --Kolja21 (talk) 01:41, 10 March 2014 (UTC)

  • Symbol keep vote.svg Weak keep. The DDBC looks like a good authority database and the property is only one month old. Let's wait some more time. Mushroom (talk) 11:43, 7 April 2014 (UTC)
  • Symbol keep vote.svg Keep. It looks like a useful authority, and they say they have APIs so it should be easy to sync. I have manually added a place Id onto India (Q668). John Vandenberg (talk) 07:18, 9 April 2014 (UTC)
  • Pictogram voting comment.svg Comment I've added this property into a few more items. --Jakob (talk) 17:25, 28 June 2014 (UTC)
  • Symbol keep vote.svg Keep --Micru (talk) 10:44, 7 July 2014 (UTC)

event location (P766)[edit]

(delete | history | links | logs | discussion)

Now that we have ranks and qualifiers using event location (P766) with rank = "preferred" seems like the best solution as it is more consistent with other properties and it avoids scattering things into different properties when the object has moved. User:Zolo
Jane023 (talk) 08:50, 30 May 2013 (UTC)
User:Vincent Steenberg
Marsupium (talk) 13:46, 18 October 2013 (UTC)
GautierPoupeau (talk) 16:55, 9 January 2014 (UTC)
Multichill (talk) 19:13, 8 July 2014 (UTC)
Notified participants to Wikiproject Visual arts.--Zolo (talk) 17:59, 29 March 2014 (UTC)

Note: the consensus here seems to be that "moveable object location" (P276) or "event location" (P766) properties should be merged. Per initial support below, I have changed the deletion nomination to the higher of the two properties (from 'event location' to 'moveable object location'). Emw (talk) 03:01, 29 May 2014 (UTC)

Symbol keep vote.svg Keep event location (P766) is inapplicable for objects, it is for events only. Formal reason: steps described in {{Wikidata:Properties for deletion/Header}} was not done.Ivan A. Krestinin (talk) 21:21, 29 March 2014 (UTC)
I do not see how it makes any sense to use a different property for objects and events. (sorry for the procedure, fixed by Jakec (talkcontribslogs), though I do not think it matters that mich given that I am the property creator and I had informed on the talk page that I wanted to porpose it for deletion.)--Zolo (talk) 06:30, 30 March 2014 (UTC)
Additionally see long discussion: Property talk:P766#Widen the application for this property. — Ivan A. Krestinin (talk) 07:18, 30 March 2014 (UTC)
I do not think that the need for qualifiers is a valid reason for separating the property for events from the property for physical bodies. For many physical bodies, like mountaines, you don't really need time-qualifiers (well arguably you would but in most cases, that sounds way overkill). When the object has moved, you should mark the most recent as "preferred", which means you do not really need to read qualifiers for most purposes (you should be able to read the rank, but that is something that always needs to be done, and the best rank will soon be the only one returned by default by the Wikiparser). By contrast, using two different properties makes it more confusing for humans both on Wikidata and on Wikipedia. --Zolo (talk) 08:03, 30 March 2014 (UTC)
Mixing different relations types to one property is more confusable. There are more reasons was discussed in previous talk than you mention here. — Ivan A. Krestinin (talk) 19:56, 11 April 2014 (UTC)
As I understand your vision is based on English language where both relations are described by single word "location". But this vision creates problems for another languages where these relations are described by different ideas and different terms. — Ivan A. Krestinin (talk) 20:06, 11 April 2014 (UTC)
The only other reason I see discussed in the previous discussion is the label, but if there is no Russian word that covers both places and events, we can always had two words (as is already the case in English for discoverer or inventor (P61))--Zolo (talk) 08:12, 12 April 2014 (UTC)
@Ivan A. Krestinin: In that discussion you claimed that therethere is a problem in Russian in using the same property for the location of an object and the location of an event but oyu did not explain what that problem is. Can you give us some examples of how this could be confusing as to it is more confusing to have two properties for the same characteristic of a thing. Filceolaire (talk) 00:31, 25 April 2014 (UTC)
This is not same characteristic. Current place of movable object is not the same characteristic as point where event occurs. In Russian there is one word that describe both characteristics (место), but this is very general word. It has many another meanings: job, post, seat, position, quarter and etc. Double naming is bad idea too. So this property with be used not only for event and bodies, but in many other situations. Queries for this property will take very strange and unexpected results. This is general problem: our meaning is defined by language. Every language has unique set of basic terms. For every basic term in one language can be found only similar term in another. But found term will not exact the same. This difference will produce claims expected for one language but unexpected for another. More general terms are more variable from language to language (and in meaning of course). So creating very general and less defined properties will increase level of disorder in Wikidata. This is way from database to datahell as I think. — Ivan A. Krestinin (talk) 04:31, 25 April 2014 (UTC)
@Ivan A. Krestinin: I do not agree. By knowing what the object is we disambiguate the location pretty much surely. A location for an event or a place are absolutely no problem if we know what the instance of (P31) of the item is. What is a hell is to find this way to find the good one on a lot of almost equivalent property except their domains range. I think to build specific properties we need examples on ambiguities generated by the fact we can use a general property twice on the same item with different meanings. TomT0m (talk) 09:13, 25 April 2014 (UTC)
Your point is incorrect. If some domains are not intersected this is not point to use same property for different thinks. We must not mix different conceptions in one property. This will increase error count and make the property useless. About instance of (P31): currently it is the most undefined, conflicted and high error level property. Currently it can not be used to query object type. — Ivan A. Krestinin (talk) 16:49, 26 April 2014 (UTC)
Symbol delete vote.svg Delete -- Lavallen (talk) 07:37, 30 March 2014 (UTC)
Symbol delete vote.svg Delete per Zolo. Mushroom (talk) 09:39, 7 April 2014 (UTC)
Symbol delete vote.svg Delete harmful. TomT0m (talk) 10:22, 7 April 2014 (UTC)
Symbol delete vote.svg Delete --Marsupium (talk) 12:53, 11 April 2014 (UTC)
Symbol keep vote.svg Keep Location is constitutional for (most) events but by definition ephemeral for movable objects. I can imagine an extension of event location (P766) to objects with a very strong geographical connection like Pergamon Altar (Q158058) or Ötzi (Q171291) which were turned into "movable objects" centuries after originally coming into existence and now have located in (P276) also. -- 22:43, 11 April 2014 (UTC)
Some event-items could use time qualifiers (say: Foire Internationale d'Art Contemporain (Q653038): Parc des expositions de la porte de Versailles (Q3364319): 1999-2005, Grand Palais (Q457318): since 2006). And sometimes, large buildings are moved (Abu Simbel temples (Q134140), Shanghai Concert Hall (Q220805)). Keeping two different properties just because some things are more moveable than others seeems a bit complicated, and not really useful. --Zolo (talk) 08:12, 12 April 2014 (UTC)
I'm not convinced that Foire Internationale d'Art Contemporain (Q653038) will survive as "event" in the long run, since it really is a series of single events as "instances" and therefore more like the class Olympic Games (Q5389). At least we should keep in mind that this use of temporal and spatial qualifications might not that typical for events in general. Anyway: Events like Siege of Constantinople (Q27900), Siege of Constantinople (Q700886), and Siege of Constantinople (Q312268) are in a certain sense absolutely and irremovably connected to both the location Constantinople (Q16869) and the dates the respective sieges took place. And on the other hand (Abu Simbel temples (Q134140) probably exactly is one case mentioned above: Even if these temple(s) would be disassembled and relocated again to even more remote locations no one would state "Don't refer to Abu Simbel any more because it's in Canberra now". I'm not a native english speaker but maybe the two distinct properties are trying to reflect some subtle distinction which historically might have governed the use of the terms place vs. location. -- Gymel (talk) 09:51, 12 April 2014 (UTC)
Symbol delete vote.svg Delete I assume that event location (P766) is renamed, removing "event". It is not reasonable to distinct the location of an object regarding the type of the object. But of course, buildings remain buildings and will never be events. Thus, we broaden the domain of P766 to arbitrary objects.  — Felix Reimann (talk) 16:22, 23 April 2014 (UTC)
Symbol delete vote.svg Delete. per the discussion above. Filceolaire (talk) 00:31, 25 April 2014 (UTC)
Pictogram voting comment.svg Comment If event location (P766) is renamed to "location" or to "event or object location", that will make this property redundant. I would say to clarify the renaming first.--Micru (talk) 06:34, 25 April 2014 (UTC)
Symbol keep vote.svg Keep. Renaming event location (P766) is a prerequisite to deleting this one. Circeus (talk) 23:04, 6 May 2014 (UTC)
Symbol delete vote.svg Delete. I essentially agree with most of votes for deletion here. We shouldn't have properties for 'event location' and 'moveable object location'. Those properties should be merged into one, i.e. rename 'event location' to be 'location', copy all claims from this property into that one, and delete this property. Importantly, the 'domain' constraint the revised property should be removed. That would ensure subjects of the property are not assumed to be both 'events' and 'moveable objects'. Emw (talk) 12:45, 15 May 2014 (UTC)
Actually, since located in (P276) has the lower Property ID, wouldn't it make sense to relabel that property to 'location', and delete event location (P766)? The other property has a few thousand more claims, but I'm inclined to prefer the lower-ID property as the one to keep. What do you think, Zolo, Filceolaire, Lavallen, Marsupium, FelixReimann, Filceolaire, Micru and Circeus? Emw (talk) 13:01, 15 May 2014 (UTC)
I must say I agree with that idea, assuming moving properties over can be done automatically (ther eis no easy way to do it even manually.) Circeus (talk) 15:58, 15 May 2014 (UTC)
@Emw: Symbol support vote.svg Support  — Felix Reimann (talk) 06:49, 16 May 2014 (UTC)

Pictogram voting comment.svg Comment Zolo, Filceolaire, Lavallen, Marsupium, FelixReimann, Filceolaire, Micru, Circeus, Ivan A. Krestinin: Per the rationale and initial support above I have changed the property up for deletion from "moveable object location" (P276) to "event location" (P766). I have changed the also label of P276 to 'located in', which is more in line with Semantic Web conventions like the 'locatedIn' property in Per that OWL note, I'll plan to mark the updated located in (P276) property as transitive. It should also be a subproperty of part of (P361) (do we not have a template for this yet?). Please quickly indicate below whether you support all of this or oppose any of it, so we can conclude this nomination and begin cleaning things up. Emw (talk) 03:01, 29 May 2014 (UTC)

Deleting event location (P766) is fine with me. I have not completely thought through the subproperty of "part of" thing, but that can be further investigated later if needed. --Zolo (talk) 04:53, 29 May 2014 (UTC)
Oh and there is also located in place (P1134). I can't see any difference. --Zolo (talk) 04:57, 29 May 2014 (UTC)
Ivan A. Krestinin I have carefully read your disagreement above and I still have no idea what you think the problem is. I just know that you think there is a problem. If you want me to change my !vote then please describe an actual use case where having one 'located in' property would create a problem and what that problem would be. Filceolaire (talk) 20:12, 30 May 2014 (UTC)
Ok, I try again. Our mind is defined by language. Wikidata is multilingual project. Every language has different set of terms. The most of terms have correspondences in different languages. But only a little number of such correspondences are exact the same correspondence. For example English term "location" is correspond to Russian "место". But these are not exact the same terms. For example claim Xi Jinping (Q15031) <место> General Secretary of the Communist Party of China (Q849418) is valid for Russian language, but Xi Jinping (Q15031) <location> General Secretary of the Communist Party of China (Q849418) is invalid. Russian-language users will use property named "место" for claims like Xi Jinping (Q15031) <место> General Secretary of the Communist Party of China (Q849418) too. Such claims will be unexpected for English-language users. Inverse situation is possible too. Usually the more general term has more differences from language to language. So more general properties will generate more unexpected/error cases. The way to avoid this problem is creating strong defined specialized properties. Such properties can be well described by concrete label in every language. Its domains can be controlled automatically. — Ivan A. Krestinin (talk) 20:59, 30 May 2014 (UTC)
Ivan, thanks for the thoughtful response. The Russian word "место" translates to "place" in English, which is roughly synonymous with "position". Xi Jinping (Q15031) position General Secretary of the Communist Party of China (Q849418) is also valid in English while Xi Jinping (Q15031) located in General Secretary of the Communist Party of China (Q849418) is not. (The preferred property there is Xi Jinping (Q15031) position held / занимаемая должность (P39) General Secretary of the Communist Party of China (Q849418).)
Is there some word or phrase in Russian that suggests the spatial location of the subject is within the spatial location of the object? Would "расположен в" work? Emw (talk) 16:48, 31 May 2014 (UTC)
"расположен в" is inapplicable for events and movable objects, only for unmovable objects. But I described general principle. Ever we find some good words for Russian-English pair, but another languages can have same problems. — Ivan A. Krestinin (talk) 05:59, 1 June 2014 (UTC)

tennis doubles ranking (P1119)[edit]

(delete | history | links | logs | discussion)

Redundant with P1118.--Filceolaire (talk) 00:09, 19 April 2014 (UTC) Replace tennis singles ranking (P1118) and tennis doubles ranking (P1119) with a generic 'Ranking" property that can have the qualifier sport (P641) so it can be used for all sorts of sports that publish rankings. It can also be used as a qualifier in competitions and elections to record which participant (P710) was 1st, 2nd, 3rd etc.

In tennis, most players have two rankings simultaneously, one for single play, and one for double play. As far as I'm aware, for mixed-double there is no ranking, therefor that property has not been requested. I would support the creation of a new property "sports ranking" that might be useful in other sports, but for tennis we would need these two anyways. Edoderoo (talk) 22:50, 19 April 2014 (UTC)
There is probably as many ranking that there is sport organisations. I would propose to use a generic ranking properties with a qualifier to precise of which ranking we are referring to. TomT0m (talk) 09:42, 20 April 2014 (UTC)
@Edoderoo: You don't need two special properties for singles and doubles tennis. Just have Ranking (P????) with 2 values. One with qualifier sport (P641) = Singles tennis and the other sport (P641) = doubles tennis. Filceolaire (talk) 00:17, 25 April 2014 (UTC)
  • Pictogram voting question.svg Question I agree 100% with this deletion request, .. however ... as I understand it, Wikidata Client cant access qualifiers at the moment, so there is no way for infoboxes to differentiate between two values for the same property..? If so, I think Wikidata's duty to be useful for infoboxes means this deletion should be put on hold until Wikidata Client allows properly structured data. John Vandenberg (talk) 07:03, 25 April 2014 (UTC)
    Wikidata Client can access qualifiers, but it require support from Lua-modules. -- Innocent bystander (talk) (The user previously known as Lavallen) 15:11, 20 May 2014 (UTC)
  • Pictogram voting question.svg Question As ranks change, how would the history of both rankings be mixed in one property? --- Jura 15:29, 10 May 2014 (UTC)
Jura: Use sport (P641)=<singles tennis> and start date (P580) as qualifiers to note when a singles ranking was first achieved and end date (P582) when it changed. Similarly for doubles. This means a tennis player might have twenty values for this property, each with three qualifiers. Mark both the current values (singles and doubles) as 'preferred' Filceolaire (talk) 20:19, 30 May 2014 (UTC)
Though "singles tennis/doubles" is not a "sport or discipline" (btw those words means almost the same in Finnish), but "tennis" alone is. --Stryn (talk) 17:15, 23 June 2014 (UTC)
Symbol delete vote.svg Delete I started already a new property proposal for the generic property 'ranking' because in dewiki there's the wish that the rankings of table tennis players get stored in WD. --Pasleim (talk) 11:39, 30 May 2014 (UTC)
I see User:Pasleim's proposal has now been approved as ranking (P1352) so we should delete both tennis singles ranking (P1118) and tennis doubles ranking (P1119). Filceolaire (talk) 21:18, 13 June 2014 (UTC)
Symbol delete vote.svg Delete As a simpler solution is available. Snipre (talk) 08:08, 27 June 2014 (UTC)

super language family (P133)[edit]

(delete | history | links | logs | discussion)

The property super language family (P133) shouldn't be used, as the property is not specific, with only broad values being correct, while the usage of part of (P361) with a value of a more specific language family would have the same information, but with more details. This is following Wikidata:Requests for deletions/Archive/2014/Properties/1#Taxonomic rank properties. Ebe123 (discuter | contributions) 01:46, 21 April 2014 (UTC).

It seems super language family (P133) was wrongly created, as in the request it is stated "The full classification could be calculated through the specific class of the language to its class and so on." I believe "specific class" meant the most specific class, and not the broadest, as it is currently. Ebe123 (discuter | contributions) 14:48, 23 April 2014 (UTC)
I think this should be deleted. It is more useful to include the "next up" language family, not the top one. Also it is not clear whether proposed groups like "Altaic" would be added as a claim for every Turkic language, etc. πr2 (t • c) 23:50, 23 June 2014 (UTC)

Symbol delete vote.svg Delete part of (P361) is sufficient and more useful. super language family (P133) does not manage the languages that are not linked to any language family. Pamputt (talk) 20:44, 10 July 2014 (UTC)

@Pamputt: I think subclass not part, when reading Help:Basic membership properties. Tamawashi (talk) 13:45, 11 July 2014 (UTC)

Symbol delete vote.svg Delete subclass of (P279) is sufficient. See Wikidata:Item classification. Tamawashi (talk) 13:45, 11 July 2014 (UTC)

earliest date (P1319)[edit]

(delete | history | links | logs | discussion)

(@AdamBMorgan, Jakec:)

This will eventually be taken care of by the time datatype itself, so there's no need for this property. --Yair rand (talk) 17:57, 21 May 2014 (UTC)

  • Symbol keep vote.svg Keep until the time datatype does so. --Jakob (talk) 18:08, 21 May 2014 (UTC)
  • Symbol keep vote.svg Keep I assume that the popularity would increase if either general examples for all properties would be available or there would be an example usage property / qualifier which might be added "inline" in WD data. (GND has such examples.) I could find only{{URLENCODE:claim[570]{claim[1319]}|QUERY}} occurences together with date of death (P570)
    Unfortunately autolist does not provide direct qualifier search; i.e. you need to query all prop values ...
    FYI: https links do not recognize the ?q= parameters. Regards gangLeri לערי ריינהארט (talk) 15:15, 25 May 2014 (UTC)
    • It was put up for deletion just two days after creation. --- Jura 05:37, 26 May 2014 (UTC)
  • Pictogram voting question.svg Question When will "eventually" be? --- Jura 05:37, 26 May 2014 (UTC)
  • Symbol keep vote.svg Keep It has some use as qualifier of unknown dates. --Micru (talk) 08:17, 27 June 2014 (UTC)
  • Symbol keep vote.svg Keep until a better solution comes up. As long as there is no other solution, it is necessary. --FocalPoint (talk) 08:54, 5 July 2014 (UTC)

disabled person (Q15978181)[edit]

  • Q15978181 seems to be a target of a property, but is not in use. Hence it was requested for deletion at the Wikidata:Requests for deletions, but I'd like to check here if there is any objection. the Requests for deletions is put on hold for now, but if there is consensus here, it can be deleted. - Tengwa osse.svgTengwa rómen.svgTengwa osse.svgTengwa óre.svg - (talk) 14:41, 28 May 2014 (UTC)
What property might that be? IIRC (cf. Wikidata:Requests for deletions/Archive/2014/04/28#Related items for disabled people) a handful of items was created by a certain user in an attempt to establish an 1:1 correspondence between Wikidata items and other systems for "controlled vocabulary" like honorific suffix (P1035) and GND identifier (P227). IMHO this gravely conflicts with the Wikipedia-induced way of organizing knowledge here and therefore the remaining three items should be deleted. -- Gymel (talk) 17:20, 28 May 2014 (UTC)
It relates a clearly identiable concept exposed in the GND ontology, we all know disabled people, i Symbol oppose vote.svg Oppose the deletion per WD:N. But I'd merge the item if there is some equivalent item to save the GND mapping. TomT0m (talk) 18:10, 28 May 2014 (UTC)
If we keep items like this, we should add a note to WD:N. And we have to decide what happens with the female form "Weibliche Behinderte" that is right now part of the German label "Behinderter / Behinderte". --Kolja21 (talk) 21:52, 28 May 2014 (UTC)
Subclassing human (Q5) might not be broad enough, the OP used the items to make some nordic deities an instance of them. Thus person (Q215627) might be a more appropriate superclass, but then the use with instance of (P31) is prohibited. The "Wikidata way" probably would be medical condition (P1050) together with handicap (Q12131) or a more specific denomination and avoids the pitfalls of implying biological species or gender or whatever problems might arise when trying to reflect the categorical hierarchy below Category:People with disabilities (Q6483361) to proper items.
As to the GND ontology (you obviously are not referring to the GND ontology): The GND itself is an "authority file", implying weaker expectations with respect to internal consistence than e.g. a thesaurus. For Behinderter it relays the definition of the concept to a certain edition of Der Große Brockhaus but furthermore gives a usage note (which strictly spoken only applies when using GND vocabulary within the context of subject cataloging by the RSWK ruleset): "Use only when attributes of this group of people (e.g. unemployment) or the relation to other groups of people are to be described. Otherwise use "Behinderung" [i.e. handicap (Q12131)], also in connection with rehabilitative, therapeutic etc. treatments. In conjunction with specific groups of persons use the combination with "Behinderung", e.g. Student ; Behinderung, Schüler ; Behinderung". Clearly the GND is trying to restrict usage of personalized form if favor of the topical term whenever possible, probably for similar reasons as outlined above.
Reference to the Brockhaus encyclopedia backs the claim that disabled person (Q15978181) is a "cleary identifyable concept" in the sense of WD:N but the underlying bare-bones concept is handicap (Q12131). I would assert that any specific application of the concept as in disabled person (Q15978181) tends to open a conflict between "clearly identifiable" (e.g. not to be used figuratively) and "broadness" of application. Thus as long there is no demonstratable use for disabled person (Q15978181) within Wikidata I'd rather like not to have it. -- Gymel (talk) 23:53, 28 May 2014 (UTC)
+1. Same for mentally disabled person (Q16649023). --Kolja21 (talk) 21:17, 29 May 2014 (UTC)
@Gymel: OK for the GND definition applied to deities, which we do not do in Wikidata. But it's enough to make it a subclass of human (Q5) (View with Reasonator) for excluding deities are they won't be instances of human. Maybe this class is more equivalent to the union of the instances of the fictional analog of (P1074) <disabled people> and the plain <disabled people> classes instances. But defining this class for human only is perfectly possible in OWL for example. In this language, classes can be formally defined by the properties and property values of items. If we define the <disabled people> class as items which are humans and with a Template:Medical condition claim with a value which is an instance of a handicap, then we made properly the link. Actually this can really be useful for querying, for example if you want to query the blind musicians, with a <blind people> subclass of <disabled people>, this can make the query very simple. Maybe this would duplicate the disabilities classification, which is the only drawback I can see, but maybe not, the disabilities classification would probably be way more developped while the human subclass tree can be restricted to socially used classes (physical, mental, sensitive ...) and be less extensive. TomT0m (talk) 19:16, 31 May 2014 (UTC)
What I was aiming at was the following: The only use case known as yet were handicapped deities ("persons", not "humans") which should be excluded by Wikidata policy. For me this shows that the "orthogonal" property medical condition (P1050) with the specific kind of handicap as value is the much more appropriate way to go and the need for precombined classes like "handicapped person", "handicapped human", "handicapped human female", ... still has to be demonstrated. The fact that there is some language with a noun (eg. "Behinderte" in german) should not automatically make this noun Wikidata-notable. -- Gymel (talk) 23:53, 31 May 2014 (UTC)
@Gymel: The orthogonal nature of the property does not imply such a class definition cannot be made. For example I just read an article about the geometry abilities of blind mathematician. I think the clases blind people or deaf are widely used socially and really useful in real life, and not only to point a type of disability, but more to point the people who have this caracteristic. This does not imply we create all combination of classes such as blind people which wrote a song between midnight and 2 in the morning in 1958, which have no practical realities at all. There is a big open space beetween almost no classes and this extrimity :) One lesson from the OWL models is that it's not because there exists properties that the class is not useful, actually properties are used to define classes. TomT0m (talk) 09:23, 1 June 2014 (UTC)
Looking at the current tree of subclasses of human (Q5) professions (and related activities like war criminal (Q15966439)) are predominant. Probably most of these items are not linked to articles but I agree with their WD:N because they come handy when characterizing human (Q5)'s by means of instance of (P31), i.e. use the subclass of human (Q5) depicting the field which makes the item at hand notable. And because professions are properties (almost exactly) restricted to the domain of instances human (Q5). In the tree there are also beginnings of additional hierarchies, like sex (woman (Q467)), relative socio-biological concepts (child (Q7569)), ethnological (Arab (Q35323)), geographical (French people (Q121842)), professional ranks corporate title (Q1072363), and more: To most humans all of these approaches simultaneously apply, but usually are noted by properties like sex or gender (P21), if notable at all. Certainly we do not intend a future wikidata where most humans have a dozend instance of (P31) with some of them of preferred rank. However thinking in terms of instance of (P31) any of these alternate subtrees of human (Q5) might be appropriate in theory: perhaps the notability of the mathematician in your example above is solely founded on his blindness, not his mathematical achievements. Specifically for handicaps and physical features of humans I do not know of one single example at the moment where an item of this kind would be helpful and I see the problem that one would have to construct a hierarchy tree of these impairments without being backed by wikipedia articles - I would consider this the wikidata equivalent of Wikipedia:No original research (Q4656524).
Again: I quite agree that any item of the kind "human (Q5) intersected with some property" is theoretically legitimate. But we should not create (or retain) them unless they are actually used here. And "because some language has a word or phrase for it" should not be considered a sufficient argument for WD:N. -- Gymel (talk) 11:07, 1 June 2014 (UTC)
@Gymel: You're kidding ? Ludwig van Beethoven (Q255) (View with Reasonator) is famous for beeing a deaf composer. Ray Charles (Q544387) (View with Reasonator) is famous for beeing blind. Helen Keller (Q38203) (View with Reasonator) for beeing both. Oscar Pistorius (Q201377) (View with Reasonator) (first) for beeing a disabled sportsman. Here is a full website whose it is the subject. TomT0m (talk) 11:51, 1 June 2014 (UTC)
You are saying it yourself: Ludwig van Beethoven (Q255) instance of (P31) composer (Q36834) and he also was deaf later in his life. We normally don't consider it appropriate (here) to describe him as a deaf person who composed (although in theory again other persons already born deaf practiced some musical composing and are remarkable as deafs) or to regard him as someone in the intersection of composers with deaf people. For Pistorius I have no objections if a "profession" item reflecting Disabled sports (Q814517) would exist. Keller seems to be difficult. -- Gymel (talk) 12:08, 1 June 2014 (UTC)
There is nothing difficult here. A disableness is often a really important part of the identity of a person. It's not really open to debate IMHO. The slippery slope is not really an argument in these conditions (for example you don't play disabled sport if you aren't, we could have a constraint stating that the domain of the players of such a sport are disabled people). TomT0m (talk) 12:17, 1 June 2014 (UTC)

(no label) (P1298)[edit]

Duplicate of work location (P937) --Rippitippi (talk) 17:45, 9 June 2014 (UTC)

Indeed. -- Gymel (talk) 21:44, 9 June 2014 (UTC)
Symbol delete vote.svg Delete --Pasleim (talk) 01:08, 11 June 2014 (UTC)
Pictogram voting comment.svg Comment Labels and descriptions in French and English could use some work. --- Jura 11:36, 14 June 2014 (UTC)
Symbol delete vote.svg Delete I was just going to suggest this myself. Usage: 937, 1298 Danmichaelo (talk) 23:28, 14 June 2014 (UTC)
Symbol delete vote.svg Delete Snipre (talk) 12:18, 16 June 2014 (UTC)
✓ Deleted --ValterVB (talk) 19:31, 5 July 2014 (UTC)

CHRC (P616)[edit]

(delete | history | links | logs | discussion)

Redundant to Iranian National Heritage registration number (P1369).--دوستدار ایران بزرگ (talk) 18:23, 22 June 2014 (UTC)

Why not delete the higher numbered one then? --Jakob (talk) 13:55, 27 June 2014 (UTC)
The first one had some technical problems! That is the bot is working on the second one.--دوستدار ایران بزرگ (talk) 16:19, 28 June 2014 (UTC)

applies to jurisdiction (P1001)[edit]

(delete | history | links | logs | discussion)

Originally this property was supposed to mean that an item is under jurisdiction of an entity. Over time it took up other roles like an item applies to a certain jurisdiction and that an item contains certain jurisdictions. Currently it is a mess, so I propose to deprecate this property and create 3 more specific properties:

  • is in jurisdiction of
  • contains jurisdiction
  • applies to jurisdiction

Which are the current uses of p1001.--Micru (talk) 10:40, 7 July 2014 (UTC) No longer valid, see new deletion proposal below. --Micru (talk) 08:32, 10 July 2014 (UTC)

Pictogram voting question.svg Question @Micru: How is "in the jurisdiction of" different than is in the administrative territorial entity (P131)? And how is "contains jurisdiction" different than contains administrative territorial entity (P150)? --Closeapple (talk) 10:59, 7 July 2014 (UTC)
@Closeapple: So far I haven't seen any use of p131 other than to denote government-related entities. If other uses were acceptable, then I still think it is necessary to reboot p1001. It has too many inconsistent uses and the labels in other languages refer to different concepts.--Micru (talk) 11:08, 7 July 2014 (UTC)
@Micru:: If is in the administrative territorial entity (P131) is just for other administrative entities, I'm in trouble: I just added it to a bunch of other geographical items yesterday. I think is in the administrative territorial entity (P131) and contains administrative territorial entity (P150) would work (and are being used) for the first two replacements. --Closeapple (talk) 11:51, 7 July 2014 (UTC)
Symbol neutral vote.svg Neutral on deletion of P1001 specifically. (My only knowledge is about the suggested replacements.) --Closeapple (talk) 11:51, 7 July 2014 (UTC)
@Closeapple: alternatively all labels and descriptions from p1001 could be deleted so the users can translate the current label into other languages, with the hope that the wrong uses of this properties will be corrected over time.--Micru (talk) 08:06, 9 July 2014 (UTC)
Symbol oppose vote.svg Oppose deleting applies to jurisdiction (P1001) only to replace it with a new property which is also called 'applies to jurisdiction'. If the P1001 is being used where is in the administrative territorial entity (P131) or contains administrative territorial entity (P150) are more appropriate then ammend the description to make it clearer how it should be used and add some aliases to P131 and P150 so they show up in searches for 'jurisdiction'. If there is a real use case that isn't covered by these three existing properties then propose the creation of that additional property. Nothing you have said above justifies the deletion of P1001. Filceolaire (talk) 08:14, 10 July 2014 (UTC)
@Filceolaire: I think you are opposing the original deletion proposal, but that has changed (see below). The current proposal is to deprecate p1001 in favour of a generic "applies to" property (based on p:p518). Of course while p1001 is deprecated there would be time to move the statements either to "is in administrative territorial entity" or to "applies to".--Micru (talk) 08:32, 10 July 2014 (UTC)

New deletion proposal[edit]

Snipre suggested to delete this property and merge it with a more generic "applies to" (based on p:p518). I think it might be a good idea.--Micru (talk) 12:25, 9 July 2014 (UTC)
Symbol delete vote.svg Delete With merge with p:p518 in a general property "applies to". Snipre (talk) 12:41, 9 July 2014 (UTC)

I have no objection. - Brya (talk) 16:44, 9 July 2014 (UTC)

Pictogram voting question.svg Question: Is this a proposal to use applies to part (P518) in most cases, or to create a new property that is similar to P518? --Closeapple (talk) 12:39, 10 July 2014 (UTC)
@Closeapple: I have suggested to extend applies to part (P518) (See: Property_talk:P518#Generalizing_this_property), but I don't know yet if there is any objection.--Micru (talk) 13:16, 10 July 2014 (UTC)