Wikidata:Properties for deletion/Archive/2014

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

Property:P54 (member of sports team)

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 is to keep this property. Any further discussion as to what to do with it from here should be directed to the property's talk page. T C N7JM 05:35, 23 January 2014 (UTC)

Keep This is one of those cases where I feel that merging to a broader property will create more issues than it solves. The average professional footballer will play for several clubs, and if they're good, also the national team, the under 17 national team, the under 19 national team, and so on. But what if they're also a member of a philanthropic organization or a national Olympic committee? Then you're mixing up two very different types of organization in one property, and that's going to be a pain to work with. Sven Manguard Wha? 04:52, 15 November 2013 (UTC)
I'm skeptical of that claim. All you have to do is check the related item for what kind of organization it is. This is most certainly a property that could go the way of the dodo. --Izno (talk) 18:52, 17 November 2013 (UTC)
You can also be a member of a sports club without playing for it, like e.g. John Paul II (Q989) has been a member of FC Schalke 04 (Q32494). This case could be distinguished by a "type of membership" qualifier (active member, passive member, honorary member, executive member, ...), but I think a dedicated property would be easier. Then again, P54 only says that someone "represents" that club. --YMS (talk) 16:13, 15 December 2013 (UTC)
Delete, per the nomination and per my disagreement with Sven. --Izno (talk) 18:52, 17 November 2013 (UTC)
Delete Once you know all the organizations the person is "member of", you can filter them by organization type. This property is redundant.--Micru (talk) 22:37, 24 November 2013 (UTC)
Keep I see a huge difference between team membership (always qualified by a period of time) and "club" membership in an organization (beginning and end usually not known). Therefore member of sports team (P54) should be refined to teams/cadres and the like: As already pointed out a soccer club might have members, IIRC the players in its professional teams (plural!) are employees and one would have to check their contracts to decide whether they are obliged to be club members (and in this case they would not meet the "free will" criterion of member of (P463)). member of (P463) might simultaneously apply with "employee"-qualified relation to the club. -- Gymel (talk) 11:09, 28 December 2013 (UTC)
Keep They may sound and spell similar but they are two different items/objects. This one here just describes if someone was "playing for" some organization, the other being a "member of" some organization. Maybe it should be renamed or added a clearer description?! --Mirer (talk) 16:54, 10 January 2014 (UTC)
Keep per Sven Manguard. --Stryn (talk) 09:13, 12 January 2014 (UTC)

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

Property:P1089

P1089 (P1089): (delete | history | links | entity usage | logs) Wrong datatype: should be number instead of media. Thanks! --Paperoastro (talk) 09:06, 31 January 2014 (UTC).

Sorry, my fault. Must have misclicked. Will take care of it. --Tobias1984 (talk) 09:09, 31 January 2014 (UTC)

Taxonomic rank 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.

As per Succu's summary, these properties have been marked as deprecated. --Jakob (talk) 14:57, 12 February 2014 (UTC)

Use parent taxon (P171) instead. see [1].--GZWDer (talk) 05:26, 22 October 2013 (UTC)

This is folly. Many taxons change over time exactly because those intermediate taxons are deprecated or included or whatever. Without this information this cannot be expressed. Thanks, GerardM (talk) 08:50, 22 October 2013 (UTC)
I am confused, if intermediate taxa are unstable, that seems like a good reason to favor computing them using parent taxon (P171) rather than hardcoding them, as it will minimize the number of items to update. What am I missing ? --Zolo (talk) 09:57, 22 October 2013 (UTC)
Maybe if the items shouldn't be updated, but be complemented instead? If scientific article A by scientist B et al, in 197X told that C was a specie in genus D of family E, and we today, since 199Y instead tells C is a specie of genus F of family G. Then it is large risk that the relation between C and E will be hard to find in the tree of inheritance. -- Lavallen (talk) 11:56, 23 October 2013 (UTC)
Thats what 'end date' qualifiers are for. We should have values for 'Parent taxon' for each of the various taxa which have been used in the past with an end date for when it stopped being used. Filceolaire (talk) 16:14, 23 October 2013 (UTC)
That is true, but I am not always sure that statement A automaticly gets an end date, with the start date of statement B in cases like this. It's not even always true in cases of geographic inheritance. -- Lavallen (talk) 16:34, 23 October 2013 (UTC)
To me "C genus: D, end date: 2000 ", means "in 2000, C ceased to be in genus D, not , in 2000, a new study found that C was actually not part of genus D. The new study says that C has actually never been in genus D, not that is was in genus C until 2000 and stopped being in it after 2000.

I think Lavallen's point is valid, even though I do not know how important it is in practice. If article A was only about species C, then it is probably important to know that it classified it in genus D. Is it also important to know that it classified it in family E ? I would imagine that the article's author did not think much about it, the topic of his article is the relation between C and D, not between D and E. --Zolo (talk) 21:17, 23 October 2013 (UTC)
There are two things that make this not-a-problem:
1. Qualifiers. "Date of scientific description" is probably the best one to use.
2. Rankings. These will allow us to show what the preferred taxon is now. I don't know the specifics of how they will work, but I expect that I will be able to have multiple first-order rankings on a particular claim—thus indicating that the classification of an item is currently in dispute.
As a third point somewhat, the fact that they change over time still makes these relations duplicates to "parent taxon". --Izno (talk) 00:17, 24 October 2013 (UTC)
How to use parent taxon (P171) in Template:Taxobox (Q52496)? — Ivan A. Krestinin (talk) 18:18, 23 October 2013 (UTC) P. S. You forget notify users about this nomination.
It is not really possible before bugzilla:47930 is solved, but once it is, we would need to iterate parent taxon (P171) until we find an item with taxonomic rank "regnum" and so on. It is more complicated, but it is easier to update. --Zolo (talk) 21:17, 23 October 2013 (UTC)

How to use it is rather irrelevant to whether we should build a flexible database. As it is, the WD:Taxonomy task force as a (local) copy of taxobox that shows the proof of concept. --Izno (talk) 00:17, 24 October 2013 (UTC)
Keep at least until somebody will create Template:Taxobox (Q52496) based on parent taxon (P171). Flexible database is good idea, but there are another more important thinks: database must be usable and easy to use. — Ivan A. Krestinin (talk) 04:38, 24 October 2013 (UTC)
Must be usable when? Why now? You always seem to assert that it must be now (without saying as much), but that's not supported by anything by your opinion. I would rather a flexible database now and leave the wikis to hang (which for the most part already have the infoboxes filled in manually) rather than have to delete properties after the fact. Just see the stupidity and the time that it is taking to delete one property (GND main type). That's pain that we should do everything to prevent. --Izno (talk) 23:29, 29 October 2013 (UTC)

Actually, Template:Taxobox is using only parent taxon (P171) to build hierarchy. Infovarius (talk) 20:25, 1 November 2013 (UTC)
I would support the deletion of these properties. However, the WD:Taxonomy task force may not support deletion at this time. I'll go drop them a note. --Izno (talk) 00:17, 24 October 2013 (UTC)

My vote is fix 47930. It today looks essential to the progress of this project! I'm afraid we will stay here in terra incognita until that is solved. -- Lavallen (talk) 06:34, 24 October 2013 (UTC)

I don't see that these can be deleted at this time. This is especially true for "family", which has great practical value. Before deletion is seriously considered, a) the bug needs to be fixed, and b) "parent taxon" needs to be implemented fully (or nearly so). But certainly these properties are to be deprecated.

Do note that, as a rule, there is no "end date" for a taxonomic placement. The truism applies here that any scientific theory or viewpoint will die out only as the people who were taught it when young die out; it is a long-drawn-out process (taking decades), not one point in time.

A minor point is that "Date of scientific description" is not very useful. There exist "date of discovery", "date of first scientific description" and "date when the name was published". What is generally known is the "date when the name was published", but this may be decades, or centuries (sometimes millennia) after a taxon was discovered or first described. - Brya (talk) 05:45, 30 October 2013 (UTC)

At present the deletion of all these properties is a bad idea, because we have long constraint violation lists, which have to be processed. Thanks for creating them Ivan. But all these properties should be clearly marked as deprecated.

I see one exception: P273 (P273). P273 (P273) bears no valuable information. Most usages were created by BotMultichill how wanted to play around with properties at an early project stage. No import source is given and according to the discussion page of this property there are no external usages.

In the meantime P89 (P89) is used outside its original scope (eg 5-hydroxytryptamine receptor 2B (Q4639596) or Tyrosine-protein kinase transforming protein Src (Q13360422)). So we need a constraint that tells us when P89 (P89) and taxon name (P225) are used in conjunction. @Ivan: is this possible?

What we need is a clear, lossless migration strategy towards adopting parent taxon (P171) (in conjunction with taxon name (P225) and taxon rank (P105)) as the central feature in modeling taxon names (not taxon concepts). Next candidate for deletion is apparently P75 (P75) (see value statistics). I'd like to terminate P74 (P74) as a next step, but I feel this could be a long run. @Brya: P71 (P71) should be deleted in a final step. --Succu (talk) 17:11, 30 October 2013 (UTC)

Delete. This will take a while to implement but in the meantime these can be marked as deprecated and a note added telling people to use Parent taxon and Taxon rank instead. Filceolaire (talk) 21:01, 6 November 2013 (UTC)

Delete we should not hurry with deleting them, especially no bot runs for now. Currently, they can be used for data management, to deploy taxon name (P225), parent taxon (P171), and taxon rank (P105), and for identifying constraint violations. However, marking them already as deprecated is important as this would prevent creation of client modules. For those who doubt the applicability of P171, please see Module:Taxobox (even if still a preliminary test). — Felix Reimann (talk) 09:18, 22 November 2013 (UTC)

Delete Before to delete a well-made taxon, I would open a discussion to the Wikidata talk:WikiProject Taxonomy to evaluate pros and cons of the two different systems of classification. A small consideration: before to make these big changes, I would wait queries, to understand what system work better. --Paperoastro (talk) 10:29, 8 December 2013 (UTC) I'm sorry, I saw now the discussion in the project chat. As Emw told below, when the discussion finished and the transition was done, it can be deleted. --Paperoastro (talk) 22:56, 9 December 2013 (UTC)

Delete like FelixReimann, I think these properties should be deleted, but I don't think we need to be in a big hurry to do so. However, unlike Felix, I think the generic subclass of (P279) property would be better than parent taxon (P171) as a replacement. Emw (talk) 04:05, 9 December 2013 (UTC)
Delete use subclass of (P279). Androoox (talk) 01:54, 29 January 2014 (UTC)

If I may to summarize: It seems to me that the outcome of this proposal is clear. Mark all above properties as deprecated. Migration to complete the realations of taxon name (P225), parent taxon (P171), and taxon rank (P105) takes a while, but is underway.--Succu (talk) 23:53, 14 January 2014 (UTC)

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

visitors per year (P1174)

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.

Per the comment by Lydia and no real disagreement with her comment in 24hrs (I know a short time frame but hey) there is no reason to keep this discussion going on. Therefore speedy close as keep or however you want to call it. John F. Lewis (talk) 17:13, 28 February 2014 (UTC)

Wrong datatype. This property was created dimensionless. That looks to me like a mistake. I would prefer a unit like year^-1 or whatever time^-1-unit. Now this property is created, and in use, so I Keep for the moment, but I propose that it would be replaced as soon as a time^-1-unit is available. -- Lavallen (talk) 06:46, 26 February 2014 (UTC)

I heard that the datatype for dimensionful quantities will come with an unit converter, i.e. one can then convert a value with unit year^-1 to day^-1 etc. If this is correct, we should not change the datatype of visitors per year (P1174) because "visitor" is not a quantity which can converted from one unit to another. --Pasleim (talk) 08:45, 26 February 2014 (UTC)

Why isn't it? -- Lavallen (talk) 09:43, 26 February 2014 (UTC)

Assume a fairground which is only open during summer. One can add a statement like P1174=365,000 but one can not conclude that the fairground had 1,000 visitors per day, 36,500,000 visitors per century or 0.012 visitors per second. --Pasleim (talk) 10:24, 26 February 2014 (UTC)

I don't think the numbers are comparable. Visitors per year is good for places that are open all year (like airports). Visitors per day is good for places that have seasons (skiing lift, public pool, ...). A simple conversion will always put seasonal places behind always-open places. --Tobias1984 (talk) 10:06, 26 February 2014 (UTC)

Well, if the heartbeat is 60 bpm, does not mean that it beat every second, so that is not a problem only related to "visitors". I hope the developers will make this datatype in a way that it is visible what unit the user added. -- Lavallen (talk) 13:00, 26 February 2014 (UTC)

This property can be used for the number of visitors in a specific year (e.g. for museums, archaeological areas, theatres...) with the qualifier point in time (P585). --Paperoastro (talk) 13:10, 26 February 2014 (UTC)

Hey :) John asked me to comment here. The current plan is to have the quantities datatype be for both quantities with and without a unit. --Lydia Pintscher (WMDE) (talk) 18:53, 26 February 2014 (UTC)

@Lydia Pintscher (WMDE): Is my understanding correct that the implication of your statement is that "there is no need to change the data type, you just need to wait". Is that a correct understanding? --Izno (talk) 23:03, 26 February 2014 (UTC)

I can't say for certain yet. We have not talked through the exact details for units yet. I'll try to get to that next week. --Lydia Pintscher (WMDE) (talk) 00:05, 27 February 2014 (UTC)

Given that we have bots, it is not smart to delete properties whose values can be converted to an other value at this time. Also given a definition it can be understood what a property is there for and how to understand it. Thanks, GerardM (talk) 06:14, 27 February 2014 (UTC)

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

P295 (P295)

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. A summary of the conclusions reached follows.

Consensus to delete, and use part of (P361) instead. Ajraddatz (Talk) 00:38, 5 March 2014 (UTC)

P295 (P295): (delete | history | links | entity usage | logs) Forgive me if this has already been covered but I don't understand why we would need a separate property for "...range or group of mountains that the subject is a part of" when we also have a "Part of" Property:P361 that could easily accommodate such groupings (similar, I would argue, to how it now does for Lake Superior being part of the Great Lakes). Shawn in Montreal (talk) 18:48, 26 November 2013 (UTC).

Comment: Haven't you been one of the supporter for creating that property, see [2] ? --Zuphilip (talk) 19:12, 4 December 2013 (UTC)
I laughed! Maybe he is regretting his decision then. :) --Izno (talk) 23:12, 4 December 2013 (UTC)

Holy smokes, you're right. But P:361 hadn't existed as yet -- by about two weeks -- and so I hadn't realized we could just have a general "part of" property. Shawn in Montreal (talk) 02:00, 7 December 2013 (UTC)

Delete as a duplicate to part of (P361). --Izno (talk) 23:12, 4 December 2013 (UTC)
Delete. "P295 (P295)" is no duplicate of "part of (P361)" but a more specific case: a "mountain (Q8502)" may be connected via "part of (P361)" to other things too. However the property can be inferred from those "part of (P361)" that link to a "mountain range (Q46831). -- JakobVoss (talk) 20:28, 14 December 2013 (UTC)
Delete. Should be merged with part of (P361). --Jakob (Scream about the things I've broken) 21:03, 14 December 2013 (UTC)
Delete. Should be merged with 'located in/on physical feature (P706)'. Filceolaire (talk) 07:59, 20 December 2013 (UTC)
Delete. Should be merged with P361 --Goldzahn (talk) 13:27, 6 February 2014 (UTC)

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

P1205 (P1205)

P1205 (P1205): (delete | history | links | entity usage | logs) Sorry, wrong data type. My fault.--Kolja21 (talk) 02:44, 10 March 2014 (UTC)

Deleted --Pasleim (talk) 08:35, 10 March 2014 (UTC)

Commons gallery (P935)

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 is to keep this property. Lavallen (talk) 12:14, 14 March 2014 (UTC)

Now that we have Commons support, we can just add a sitelink to Commons. --Jakob (talk) 16:08, 26 February 2014 (UTC)

This is relevant for this property only. Commons category still needs to exist but this is about the gallery property. Unless people have a reason to keep this, I'm going to simply comment and not !vote since I closed the RfC around this. John F. Lewis (talk) 17:03, 26 February 2014 (UTC)
Keep - sitelinks must be unique, this property allows to use the same link in more articles or more links in one article. And additionally - this property is used by several wikis, so you should inform them and rewrite all templates which ude it. JAn Dudík (talk) 19:27, 26 February 2014 (UTC)
@JAn Dudík: We have zero obligation to any wikis using this property. And especially, we have zero obligation to fix their templates. If their templates break, that is their issue, not ours. --Izno (talk) 22:59, 26 February 2014 (UTC)
@JAn Dudík: It's simple to replace this property with interwiki by the help of Wikidata. I have already started with that between Wikipedia and Wikisource. But that is of course the case only when there is a 1:1-relation between the WP-arcticles and the Galleries. I thought that was the case. Can you give us any examples where it isn't? -- Lavallen (talk) 06:58, 27 February 2014 (UTC)
Probably there is a 1:1-relation between WP-articles and Galleries. But with Commons gallery (P935) we can also make the link between a WP-category and a gallery. --Pasleim (talk) 12:18, 27 February 2014 (UTC)
You cannot today follow the track: category's main topic (P301) -> commonslink, today, but you will (I hope) in the future. -- Lavallen (talk) 13:14, 27 February 2014 (UTC)
Keep One item can have more than one gallery associated with it. For example a building can have one gallery for exterior, one for interior and one for the construction. ℇsquilo 13:45, 6 March 2014 (UTC)
En vettig motivering! -- Lavallen (talk) 18:33, 7 March 2014 (UTC)
Keep if it is true that the main gallery of an item can (and must) be linked with sitelinks, other involved galleries cannot, as ℇsquilo example, above. I don't know if in future we can add more than one Commons sitelink to one item, but at now this property can be useful. To avoid duplicated information, I propose to rename it "other galleries on Commons" or similar. --Paperoastro (talk) 10:48, 12 March 2014 (UTC)

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

Commons category (P373)

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 is to keep this property. Lavallen (talk) 12:15, 14 March 2014 (UTC)

Keep This is different from the above, because it is apparently against the rules to have sitelinks to articles and commons categories in the same item. --Jakob (talk) 13:29, 27 February 2014 (UTC)
Keep I disagree with Jakec, my concern is more about the 1:1-relation between Commons and all other projects. -- Lavallen (talk) 14:22, 27 February 2014 (UTC)
Keep It's also the Commons-category belonging to articles, not just the category in commons (the Commons-category for the category). - - (Cycn/talk) 13:18, 6 March 2014 (UTC)
Keep Links from articles to categories can/shall not use sitelink. This property is to be used insetad. ℇsquilo 13:40, 6 March 2014 (UTC)
Keep @GZWDer: why didn't you notify me? Isn't the header clear enough about what you have do to when you nominate something? Multichill (talk) 22:23, 10 March 2014 (UTC)
Keep This property is the only manner (at now) to link Commons categories to the respective article in Wikipedia. --Paperoastro (talk) 10:38, 12 March 2014 (UTC)
Keep A page and a category aren't the same thing : the link in "interlinks section" is for the page of the entity in commons who talk about this entity, a categoy aims to share all medias (= different entities) about this entity -- GautierPoupeau (talk) 09:14, 14 March 2014 (UTC)

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

P173 (P173)

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.

The result was delete, which will happen when all 200-odd links to the property have been removed. --Jakob (talk) 12:34, 14 March 2014 (UTC)

P173 (P173): (delete | history | links | entity usage | logs)y 2014 (UTC)

P173 (P173) suffers the same problems as the general type properties. --Izno (talk) 01:37, 11 February 2014 (UTC).
flat and not standardized classification. Delete. Use P31. — Felix Reimann (talk) 22:02, 20 February 2014 (UTC)
Comment - See also Wikidata talk:Politics infoboxs task force. -- Lavallen (talk) 08:13, 21 February
Delete Looks simple to replace... -- Lavallen (talk) 08:13, 21 February 2014 (UTC)
Delete. It is unnecessary and can be replaced with instance of (P31). This property only can take a few values, often irrelevant to specify them (stms. due to the title of the entity), being more simple instance of (P31) ≫ election, or if you want to be more precise, instance of (P31) ≫ general election, etc. --Zerabat (talk) 21:53, 24 February 2014 (UTC)
Delete As for other similar property, election can be managed using a hierarchy made with P31/P279. --Paperoastro (talk) 08:16, 26 February 2014 (UTC)
Keep as explain in the discussion Politics infoboxs task force there is no way to have constraint check if we use instance of (P31). As explain by Lavallen, it's simple to replace P173 (P173) by instance of (P31), but doing the contrary would be impossible. That's show that there is more meaning in P173 (P173) than in instance of (P31), and what is important is to have information and not only data. In the previous position I see opinions but not facts. --Dom (talk) 18:55, 2 March 2014 (UTC)
I do not know everything about constaints, but I really think the change from P173 to P31 is reversible, since all kinds of elections should be within a limited subclass. -- Lavallen (talk) 19:51, 2 March 2014 (UTC)
@Lavallen:, can you explain me how it's possible to replace instance of (P31) by P173 (P173)? --Dom (talk) 05:57, 3 March 2014 (UTC)
It's a pretty trivial replacement. The constraints can be dealt with using {{Constraint:Type}} and {{Constraint:Value type}} and other assorted constraints. --Izno (talk) 00:04, 4 March 2014 (UTC)
@Izno:My question is how will you convert the existing constraint {{Constraint:Value type|class=Q40231|relation=subclass}} that exists for P173 (P173) in instance of (P31)? --Dom (talk) 06:26, 4 March 2014 (UTC)
You don't need to. The constraint doesn't help you do anything that saying x subclass of election and y instance of x doesn't already tell you. You're using a constraint where a constraint doesn't need to be used. --Izno (talk) 00:33, 5 March 2014 (UTC)

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

P1169 (P1169)

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.

The result was delete. --Jakob (talk) 22:08, 25 March 2014 (UTC)

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

impact factor (Q5330) data is not free, as it is derived from a curated dataset (not all journals are included), it involves subjective decisions (which papers are citable and valid citations), the creators of it do apply their own non-automated adjustments, and the official complete list is published in a non-free venue only. Thomson Scientific does issue take downs for impact factors. See http://www.harzing.com/jql.htm which states "The editor regrets to inform users of the Journal Quality List that Thomson Scientific Inc. have requested removal of the Journal Impact Factor scores from the JQL. Please destroy any previous versions of the JQL in your possession. Thomson Scientific Inc. remind academics and universities that they do not permit any republication or re-use of their Impact Factor lists." Another takedown from 2006 is http://www.sciencegateway.org/impact/ which says "The lists of Impact Factors have been removed from this site due to copy right violations.".--John Vandenberg (talk) 17:47, 7 March 2014 (UTC)

Delete, as noted above. --Kolja21 (talk) 20:14, 7 March 2014 (UTC)

Delete. I agree with John. --Randykitty (talk) 17:06, 20 March 2014 (UTC)

Oppose I put my arguments in this blog post. Thanks, GerardM (talk) 07:25, 21 March 2014 (UTC)

Comment I've read your blog post (may I say that I prefer to have such discussion on wiki?) and I think that you miss a point. Thomson Reuters does not object to the use of the IF per se. Journals can display their IF on their web sites, for example. What Thomson Reuters traditionally does object to is reproduction of their journal rankings. So mentioning an IF in the article on a journal is OK. Constituting a database that basically reproduces their Journal Citation Reports is not. --Randykitty (talk) 11:22, 21 March 2014 (UTC)

Delete Since Wikidata is a CC0 provider, we would complicate reuse if there are strings attached. Instead we could offer another property like "impact factor available at", if that makes sense.--Micru (talk) 11:48, 21 March 2014 (UTC)

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

scheduled service destination (P521)

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. This has been open for almost four months and has only attracted one comment. --Jakob (talk) 22:38, 25 March 2014 (UTC)

scheduled service destination (P521): (delete | history | links | entity usage | logs | discussion) There are too many to be mantainable. We should create several items about flight and query them for phase III. see Wikidata:Property_proposal/Archive/1#Destinations.--GZWDer (talk) 16:06, 1 December 2013 (UTC)

Keep For small airports there are not too many to maintain. Even for big airports, which have hundreds of destinations, these don't change that often. Useful for wikivoyage. Filceolaire (talk) 10:38, 21 January 2014 (UTC)

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

P60 (P60)

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 is delete and use instance of (P31) and subclass of (P279) instead. Before to delete it, we need to warn Russian Wikipedia (Q206855) to modify the template ru:Шаблон:Звезда and to move all the statements of P60 to P31 (this is the bot request). See also this discussion for the roadmap. --Paperoastro (talk) 12:24, 26 May 2014 (UTC)

Previous disscussions:

First discussion (deletion)
Second discussion (recovery).

P60 (P60): (delete | history | links | entity usage | logs) Redundant to instance of (P31). --Jakob (Scream about the things I've broken) 16:59, 3 December 2013 (UTC).

Update my vote Neutral --Zuphilip (talk) 11:15, 13 December 2013 (UTC) Keep This property is essential in the definition of several constraint violation of other properties, see [3]. ~~Formal reason aggainst this Rfd: the template {{Property for deletion}} is not added on the talk page of the property.~~ --Zuphilip (talk) 19:01, 4 December 2013 (UTC)
I just saw that this kind of constraints are sometimes (already) doubled, {{Constraint:Type|class=Q6999|relation=instance}} {{Constraint:Item|property=P60}}... --Zuphilip (talk) 07:45, 5 December 2013 (UTC)
Zuphilip, it seems you've found ways that show this property is not essential to constraint validation in other properties. If so, do you still think this property should be kept? Emw (talk) 13:45, 6 December 2013 (UTC)
@Emw: Well, I am still thinking about it. See also my comments below for P132. Moreover, it would be good to hear an opinion from Paperoastro. --Zuphilip (talk) 15:28, 7 December 2013 (UTC)
Keep even if it is a synonym for 'instance of' it is still useful for millions of astronomical objects and distinguishing them from other objects. Filceolaire (talk) 21:45, 4 December 2013 (UTC)
@Filceolaire: Could you explain why this couldn't work just as well with "instance of"? --Yair rand (talk) 22:34, 4 December 2013 (UTC)
@Yair rand:. For it to work as well with 'instance of' there would need to be a tool by which you could easily check up the 'subclass of' tree to see if you can find 'astronomical object' there. Nothing posted here has even hinted that that function exists now. When I see 'instance of' working for other domains then I'll consider deleting this but not until. Filceolaire (talk) 22:20, 5 December 2013 (UTC)
@Filceolaire: http://208.80.153.172/wdq/?q=tree%5B23054%5D%5B31,279%5D. --Izno (talk) 00:16, 6 December 2013 (UTC)
@Yair rand: and right there is my problem - it seems that Edmund Halley is an astronomical object! Filceolaire (talk) 07:54, 6 December 2013 (UTC)
The subclass tree may contain errors, but using p60 only hides the problem and dilutes maintenance work. Errors in the global "astronomical object" tree do not seem extremely consequential, as we rarely need a list containing anything from comets to galaxies, but of course, we need to fix them. We can get the list of superclasses using {{Tree}} and the list of subclasses using wikidataquery so we seem to have all what we need. Right now, there does not appear to be a terrible mismatch between the list through instance of (69921 results (query)) and the list through P60 (69695 results), and the difference might be simply be due to items having only one of the two properties, which is tiresome to check. --Zolo (talk) 12:16, 6 December 2013 (UTC)

@Filceolaire: That's a bug with the software that seems to make the permalinked version of the API trim off words. The actual item being checked is indeed Halley's Comet (Q23054), as you can see in the URL. It's probably worth a report to Magnus Manske, who develops the tool. --Izno (talk) 16:05, 6 December 2013 (UTC)
Hmm, I'm not sure I see the problem. What does it do, and what should it do? Items, properties, URLs... --Magnus Manske (talk) 16:59, 6 December 2013 (UTC)
@Magnus Manske: The "root item" field in the tree of my link from 00:16, 6 December 2013 (UTC) is filled with "Halley" instead of the expected "Halley's Comet". The query is correctly returning the results expected for Halley's Comet. Now that I'm looking at it, is the apostrophe causing the word to be trimmed? --Izno (talk) 19:55, 6 December 2013 (UTC)
@Izno: Ah, I see. Thanks, fixed now. --Magnus Manske (talk) 23:57, 6 December 2013 (UTC)

@Filceolaire: http://tools.wmflabs.org/wikidata-todo/tree.html?q=6999&rp=279&lang=en ? --Zuphilip (talk) 11:31, 6 December 2013 (UTC)
That's awesome. Emw (talk) 13:45, 6 December 2013 (UTC)
Delete, in favor of labelling the classes of astronomical objects instance of <type of astronomical objects>. This is enough to be able to discriminate those classes in constraints violations and answers Filceolaire as well. TomT0m (talk) 21:54, 4 December 2013 (UTC)
I don't see any reason to introduce that when one can just query the subclass chain (which our constraint system supports!). So long as everything is subclass of (P279) or instance of (P31) astronomical object (Q6999), the constraint system will catch those issues (see {{Constraint:Type}}). Which, I expect that most such things are. --Izno (talk) 15:11, 5 December 2013 (UTC)
There is plenty of reasons, one is that there may be more than one way to class, astronomical object or other things, as there is more than one upper ontology, as one may not be interestde in the whole subclass chain and could be able to select a few of the classes. We will have tons of classes, we shoud have ways to class them. TomT0m (talk) 19:20, 5 December 2013 (UTC)
And those should be dealt with with qualifiers or sources as necessary at the time that those classes are introduced and when sufficient need is shown. What you're suggesting would annihilate the subclass tree as it is for no other reason than that you can or that you think it would be beneficial. I do not see how. :^) --Izno (talk) 16:02, 6 December 2013 (UTC)
We know the actual subclass graph is not clean as is from one the first discussion time we used the subclass visualisation tool on project chat. We showed an actual subclass tree that mixed different kind of classes, one which regrouped object by nature, the other by location. Wikidata is a complex projects, and we already need to discriminate classes by nature to show different kind of trees. This is not speculation. TomT0m (talk) 15:32, 7 December 2013 (UTC)
Delete. I think having both p60 and p96 makes things confuse as we do not really know what we should have in each. For instance, in Property_talk:P196 we have: P31 value should be a subclass minor planet (Q1022867) and p60 value should be a subclass of asteroid (Q3863), and there does not seem to be any undisputable logical reasons for that. Things would work as well with just "p31 should be a subclass of Q3863". We do not need any special property to find all instances of celestial objects: List of instances of astronomical object (Q6999) (query). – The preceding unsigned comment was added by Zolo (talk • contribs).
Delete, once, for the same reasons that we do not need any sort of main type property, and twice, because this duplicates instance of (P31). --Izno (talk) 23:11, 4 December 2013 (UTC)
Delete, redundant with instance of (P31) and subclass of (P279). Show me an ontology that uses RDFS or OWL that has subproperties for instance of (P31) or subclass of (P279). I asked for this months ago, and the response was that none could be found. I see no reason why Wikidata needs to be a unique case in the Semantic Web in this regard. Major, broad ontologies do very well with 'instance of' and 'subclass of' and without domain-specific synonyms of them like 'type of astronomical object'.
We have a gazillion domains, each of which would be a viable candidate for some synonym for instance of (P31) or subclass of (P279), if we accept that we need such properties. The fact remains that we do not. We have tools to do constraint validation using just P31 and P279, and to build subclass trees. Having 1000's of domain-specific synonyms for instance of (P31) and subclass of (P279) as this property sets precedent for would be a trainwreck of fragmentation. Emw (talk) 13:46, 5 December 2013 (UTC)
@Emw: that's a bit of a straw man. We have less than 20 properties that can be considered to be synonyms of 'instance of' and no one is suggesting we create many more. There are a number of those synonyms which do seem redundant (maybe spectral class (P215) or galaxy morphological type (P223)) but this one seems to be performing a useful function and it will be so widely used that it will help queries. Filceolaire (talk) 22:20, 5 December 2013 (UTC)
There are so few domain-specific synonyms of 'instance of' because they have been progressively deleted and routinely opposed at property proposal, not because they're remarkably useful. Even independent of that, I see no reason to consider it a strawman to assert that this property sets a precedent for a proliferation of domain-specific 'type of' properties. How doesn't it?

I also see no reason to believe such domain-specific subproperties would help queries. If they improved performance in entailment (which is a main purpose of 'instance of', i.e. rdf:type) then surely such properties would be commonplace in RDF/RDFS/OWL ontologies. But they're not commonplace at all. On the contrary, I have never encountered a Semantic Web ontology that supports domain-specific subproperties for rdf:type.

Users shouldn't need to look up different domain-specific type properties every time they want to work with type information in different domains. There should be one -- and preferably only one -- obvious way to specify the type of an instance, regardless of which branch in the tree of knowledge that instance exists in. instance of (P31) is it. Emw (talk) 05:22, 6 December 2013 (UTC)
Comment I'm strongly involved in this property. At now I don't have a good internet connection, so I cannot write my opinion here! I'll write it this night or tomorrow night. --Paperoastro (talk) 10:06, 6 December 2013 (UTC)
See http://tools.wmflabs.org/wikidata-todo/tree.html?q=6999&rp=279&lang=en. Emw (talk) 13:49, 6 December 2013 (UTC)

Comment It is frustrating to change vision and organization of a part of the project, but Wikidata is young and these are "adjustment of youth". In the past I told that in principle for me is not important how to manage astronomical objects and I opposed to the deletion of P60 for technical reasons: 1) constraints and 2) management of the hierarchy. With Constraint:Type the first opposition decayed, but at now not the second! For two reasons:

1 how do we manage a hierarchy? I made the same question when we decided to delete P107. {{Tree}} does not work (see below)

astronomical object
- natural physical object
  - physical object
    - material entity
      - independent continuant
        continuant
        entity ⊸
    - concrete object
      - object ^(#)→
  - natural object
    - object ^(#)→
- space object
  - ^→(#) object
    - entity ⊸

astronomical object
- type of object
  - metaclass
    - formal ontology concept ⊸
    - concept
      - ^∞ variable-order class ^(@)→
    - variable-order class^{∞ ↑ (@)}

even if the tool "wikidata-todo/tree.html" work very well.

2 the other general problem, imho, is the lack of rules of the application of P31 and P279. We need to answer to a simple question: where do we stop the use of P31/P279? An example: in principle we cannot use human (Q5) to define people, because we can delete occupation (P106), country of citizenship (P27), and sex or gender (P21) and use P31 with three instances. It is crazy. Analogous examples can be done using cars, buildings and so on: we can use P31 to define cars for number of tires, manufacturer, colours. In principle we could delete all the properties that are not involved in numbers and use P31/P279. I, here, make my proposal that can be discussed in other places: use P31/P279 to distinguish "real" objects/concepts each other with a hierarchy with the prescriptions of the Semantic Web and use properties for intrinsic characteristics (a hierarchy of cars include for examples supermini (Q815423) and other type of cars, but not manufacturer, numbers of tires, numbers of cylinders, colours and so on).

Returning to P60. TomT0m has right: the actual tree is confused and mixed a lot of different intrinsic characteristics! I proposed a hierarchy for astronomical objects here (I know, I "freeze" the question, sorry!) that are limited to the objects, but recently some contributors modified the tree as we can see here. How do we prevent this? This can happen in other hierarchies!

So, imho, Keep, because

Delete, but we need rules to how to make hierarchies and clean the astronomical-object tree creating new properties for the intrinsic characteristics (using the rules we defined).

--Paperoastro (talk) 00:22, 8 December 2013 (UTC) P.S.: exist a substitute of the constraint One of? In some cases no-value and some-values are used: how can we manage these values with P31/P279?

out of chronology: I modified my opinion after this comment of Emw in the discussion of the deletion of P132. --Paperoastro (talk) 21:31, 11 December 2013 (UTC)

Paperoastro, thanks for your thoughtful comment. You note several issues with P31, so I'll try to address them point by point:

P31 is used as a catch-all property

You note a major P31 antipattern, but I don't the fact that P31 is sometimes abused is reason enough to keep this particular 'type of astronomical object' property. The antipattern is using P31 as a tagging system rather than a basic membership property. This bad practice was rampant when P31 was called "is a", and is still prevalent in certain topic areas in Wikidata (here's looking at you, country subdivision task force). In its reductio ad absurdum form, the antipattern leads to the idea that "we could delete all the properties that are not involved in numbers and use P31/P279". For example, instead of structuring claims for an item something like:

Option 1:

Barack Obama (Q76)

instance of (P31) human (Q5)

sex or gender (P21) male (Q6581097)

occupation (P106) politician (Q82955), lawyer (Q40348)

position held (P39) United States senator (Q13217683), President of the United States (Q11696)

...

perhaps we could structure claims like:

Option 2:

Barack Obama (Q76)

instance of (P31) human (Q5), male (Q6581097), politician (Q82955), United States senator (Q13217683), President of the United States (Q11696), ...

Option 2 is, of course, absurd. It indicates a basic misunderstanding of P31 -- that it's OK to use 'instance of' as a tagging system. Doing this not only ruins the class hierarchy P31 is intended to help build, it more importantly dulls the expressiveness of Wikidata's property system.

The instance of (P31) property should be used sparingly on any given item. It specifies the type of an instance, which is a special property. Returning to the Barack Obama (Q76) example, 'instance of' human (Q5) tells us probably the most important piece of information about the entity 'Bararck Obama': it represents an individual human, a person. That single fact tells us an immense amount about 'Barack Obama': it is an organism (Q7239), has a mother (P25), father (P22), date of birth (P569), sex or gender (P21), etc. -- if it doesn't have a date of death (P570), you can go shakes its hand!

It doesn't make sense to have more P31 values on items like 'Barack Obama', because they are largely redundant with the statement instance of (P31) human (Q5). If we know that 'Barack Obama' is a human, then saying 'Barack Obama instance of (P31) politician (Q82955)' tells virtually the same thing, except that Barack Obama is a human with the occupation politician (Q82955). Thus, we move that value to a different property, occupation (P106), and so on for the rest of that item's properties.

Like the human 'Barack Obama', the astronomical object 'Earth' has a canonical type: planet (Q634). Like 'instance of human' gives us a way to drastically narrow down what 'Barack Obama' is, so 'instance of planet' drastically narrows down what 'Earth' is. With that simple statement, we know not only that you cannot shake Earth's hand, but also the more nuanced distinction that Earth is not a star (Q523). We do not need more P31 values for 'Earth' because they would be almost completely redundant with the statement 'Earth instance of planet'. Using P31 as such a catch-all property would be an antipattern, something to avoid.

The hierarchies created with P31/279 are unstable

In the past, the hierarchies constructed with P279 could be drastically transformed without anyone noticing. However, we now have two new tools to help monitor P279 hierachies:

1. Wikidata generic tree (see the tree for astronomical objects)

2. {{Tree}}, e.g. {{Tree|property=279|items=Q634}}, which displays as:

With those tools, user communities interested in preserving a given hierarchy can much more easily notice they're changed. Using P279 also suggests a way to dynamically maintain constraints, if we want to check to value of a property falls within its declared range (colloquially called the 'allowed values') of a property: simply iterate "up the chain" and check that that value has a P31 or P279 in the chain.

You note a few other issues, but this seems like enough to discuss for now. These points should help address your concerns for how operations could continue smoothly if we were to delete this redundant property. Emw (talk) 17:47, 8 December 2013 (UTC)

@Emw: I enjoyed reading your comments, also I am not always agreeing with you. First, I don't believe that there exists a 'canonical type' of everything (especially in a world wide database). I can believe that there are some commonly used types or some best practices. Anyway, this is maybe only loosely connected to P60.

I agree, we need 'tools to help monitor P279 hierachies', but I wouldn't say that we already have them: i) the external tools are running on data dumps which are not the newest data, ii) there is no internal version of the tree with reverse property, iii) there is no real monitor tool. Let me outline no. iii) a little further: I would suggest to add the ability to set 'watch hierarchies' in the same manner as 'watch page'. If you make a new page an include the tree template and set it to your watch list, then this will not watch at differences on the dynamic content by running the template. If you have a look at your example [4], you can't tell when the last edit was done and what changed since yesterday. I have some thought how ii) could be implemented, but maybe there are other places to discuss that. --Zuphilip (talk) 19:52, 8 December 2013 (UTC)

@paperoastro. Hi, your comment has a lot of sense. I want to put the emphasis on one thing : The use of P21 and 0279 is absolutely not incompatible with the use of P60. Moreother, the use of P31 = astronomical object can totally entail the use of P60 in usual semantic web framework.
So one note about the extreme case of putting every information in classes : it is possible. But maybe a good practice would be to define classes wrt. some values on the properties on the item, like it can be the case in OWL for example (which mean we can define the instances of a class by a query on the presence and values on properties). We really miss queries. So I see no real emergency in deleting this property, as in that sense Semantic Web classes are inherently defined partly by redudancy information. As long as it does not harms the development of the class tree as it's totally parallel and a particular case. TomT0m (talk) 17:04, 9 December 2013 (UTC)

Thank you very much Emw for you comment, clear and exhaustive. It should be in a guideline for creating hierarchies! I noted that also for "taxonomy" and "administrative divisions" there are discussions to how modify their hierarchies to use P31/P279. I'm agree with your position especially concerning "ancillary" properties. As highlighted by Zuphilip, we need more incisive instruments to check hierarchies. For example, I and other users organized the items for the property asteroid family (P744), and it was very difficult to understand from here our progresses. As noted by TomT0m, there is no real emergency in deleting this property and we can organize in the best manner the hierarchy and change the constraints to use the new features offered by P31/P279. (For example the term planetary-mass object (Q400144) is not already officially used in astronomy, so I'm not sure if use it in our hierarchy or not!). I hope developers will give us queries as soon as possible! ;-) --Paperoastro (talk) 22:13, 9 December 2013 (UTC)

Comment. Unfortunately I do not know much English, to participate in the discussion. Therefore, a practical question. As specified in the property instance of (P31), for example, for the object (145453) 2005 RR43 (Q2579791): asteroid (Q3863), trans-Neptunian object (Q6592), cubewano (Q645924) or detached object (Q2449475)? or all together? --Art-top (talk) 10:21, 8 December 2013 (UTC) Or object 4179 Toutatis (Q152907): Mars-crossing minor planet (Q777140), Apollo asteroid (Q207391), near-Earth asteroid (Q217526), potentially hazardous object (Q2014814) or asteroid (Q3863)? --Art-top (talk) 10:33, 8 December 2013 (UTC)
2005 RR43: All detached objects are trans-Neptunian, so not trans-Neptunian. It appears to me as well that all classical Kuiper belt objects are also trans-Neptunian, but are not all detached. In this case then, (145453) 2005 RR43 (Q2579791) instance of (P31) asteroid (Q3863), cubewano (Q645924) and detached object (Q2449475). --Izno (talk) 16:54, 8 December 2013 (UTC)
Well, all these entities are not all well-defined. I'm for example suprised that you describe a TNO as an Asteroid. I have considered both TNO's and Asteroids as subclasses of Minor Planets, where maybe only Centaurs and Damocloids can be in both subclasses at the same time. Another question is if Neptun trojans and other 1:1-Neptun objects are TNO's. This far I have seen them in that group, even if they fail to recognize the litteral definition. -- Lavallen (talk) 17:27, 8 December 2013 (UTC)
I made no such description, and trans-Neptunian object (Q6592) subclass of (P279) distant minor planet (Q5282923) subclass of (P279) minor planet (Q1022867) currently (which I have seen no reason to change). --Izno (talk) 17:32, 8 December 2013 (UTC)
Ok, but putting items who maybe not are recognized by everybody or are not well-defined in the hierarchy of P31/P279 may cause problems. -- Lavallen (talk) 04:30, 9 December 2013 (UTC)
When you say "not well defined", do you mean that no-one has seen fit to define them, or that definitions are loose or differing? The former we can't do much about, but as these items for the most part have Wikipedia articles, I would expect the way to deal with the latter is to source the definitions and then rank them (coming very soon!) accordingly. --Izno (talk) 14:22, 9 December 2013 (UTC)
It does not look like MPC recognize all groups we have articles about. I have seen at least one group (the OCO's) that only is recognized by a few astronomers. Another example is that some sources prefer to not separate Centaurs from Scattered Disc Objects.

If we have a claim that source X tells that object A is an instance of B. And another claim with source Y who tells B is a subclass of C. By our semantic logic we then tell that A is an instance of C. But we have no source to that claim, it's only a consequence of two related claims. If a user would have added the claim "A is an instance of C", to a WP-article, it would have been considered OR. Now that claim is added by Wikidata, and nobody make any noise about it. -- Lavallen (talk) 17:26, 9 December 2013 (UTC)
Interesting. This mean something about source inheritance and inferences which can be made with Wikidata datas. As for the classification and the class tree, classes are usually not sourced, just defined. We need to make a difference between sourced claims directly source, and deduced claims. TomT0m (talk) 17:46, 9 December 2013 (UTC)
I see that Dwarfplanets are considered a "subclass to Minor Planets". It's true that all present Dwarfplanets also are Minor Planets. But I cannot see that the definition of Dwarfplanets tells us that Dwarfplanets is a subclass to Minor Planets. -- Lavallen (talk) 19:13, 9 December 2013 (UTC)
Mmm, to understand better, is not this an extension/extension problem intensional definition (Q1026899) vs. extensional definition (Q5421961) ? ie. that the definition of dwarf planet do not imply they are all minor planets, but in practice every know darf planets are also minors ? TomT0m (talk) 21:31, 9 December 2013 (UTC)
The classification of dwarf planets and some kind of minor planets is very difficult because the argument is very recent and in this case is better use sources. In this specific case, I remember that dwarf planets are considered as minor planets, but I need sources! The problems exposed by Art-top can be resolved, imho, classifying the objects as TNO (the first) and asteroid (the second) and use the property minor planet group (P196) for the next classification. The problem of P196 is that the inner hierarchy is a to do! --Paperoastro (talk) 22:30, 9 December 2013 (UTC)
Delete. Completely redundant, per above. --Yair rand (talk) 23:02, 10 December 2013 (UTC)
Delete - is a subclass of the /property/ "instance of" and can be replaced with the latter. Androoox (talk) 18:21, 24 January 2014 (UTC)
Delete as I believe the same need is met with the generic instance-of/subclass-of, per most people above. (The lack of server-side constraints [managed by the community]--in this case, a long list a viable classes for things--seems terribly unfortunate. You know who can catch up to bot-generated constraint reports? Only other bots!) Riggr Mortis (talk) 18:53, 10 March 2014 (UTC)
Keep --Dom (talk) 19:55, 15 March 2014 (UTC)
Delete, redundant. Mushroom (talk) 09:35, 7 April 2014 (UTC)
The property is used on ru:Шаблон:Звезда. Maybe it is better to warn them before deleting. --ValterVB (talk) 08:34, 25 April 2014 (UTC)
Delete Serves no purpose since P31 exists. —Tom Morris (talk) 12:24, 26 April 2014 (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.

Consensus to keep the property. John F. Lewis (talk) 17:45, 3 June 2014 (UTC)

PROPERY:P646: no description: (delete | history | links | entity usage | logs)

Can. Sak4510 (talk) 22:24, 13 May 2014 (UTC)

Could you explain why this property should be deleted? The Anonymouse [talk] 16:02, 14 May 2014 (UTC)

Keep We can link to others, they can link to us. It will be to our benefit in the end. GerardM (talk) 18:15, 14 May 2014 (UTC)
Keep. Bizarre nomination. Emw (talk) 12:30, 15 May 2014 (UTC)
Speedy keep It seems this nomination was made by mistake. --Jakob (talk) 12:32, 15 May 2014 (UTC)
Speedy keep This nom seems like a test. --AmaryllisGardener ^talk 14:54, 15 May 2014 (UTC)
Comment This should be speedily closed as it was filed by a cross-wiki vandal (see their edits to mediawiki and meta). --Jakob (talk) 15:01, 15 May 2014 (UTC)
Delete Most of the times freebase site linked from item includes just old copy of wikipedia, links to another wikipedias or data from wikidata, so no value is added (just wasting resources of wikidate). If not deleted, usage of that property shold be limited only to freebase sites with some added value. --Jklamo (talk) 15:04, 15 May 2014 (UTC)
Delete Freebase is just copy of Wikipedia and Wikidata as I see. It can not be used for data verification, can not be used in Wikipedia templates. What applications use or will use this property? — Ivan A. Krestinin (talk) 19:54, 15 May 2014 (UTC)
Comment One edit account, see Special:Contributions/Sak4510, probably intended trolling about relationship on Wikidata and Wikibase. I say remove the proposal. TomT0m ^(talk) 20:03, 15 May 2014 (UTC)
Keep Please note a tool / gadget request at Wikidata talk:Tools#Freebase. gangLeri לערי ריינהארט (talk) 21:44, 20 May 2014 (UTC)

This is the only contribution of Sak4510. We get a new class of "contributors". See G*d does not exit. gangLeri לערי ריינהארט (talk) 21:50, 20 May 2014 (UTC)

Keep --Konggaru (talk) 10:37, 25 May 2014 (UTC)

Question @Emw:, @Jakec:, @AmaryllisGardener:, @לערי ריינהארט:, @콩가루: Could you explain your position in details? Why we need this property? What tasks will use it? — Ivan A. Krestinin (talk) 13:31, 25 May 2014 (UTC)

This is linked datas. One of the success of Wikidata at that point is the vast collection of identifier mappings such as authoritative databases, and specialized databases such as MusicBrainz and others. Freebase is a major database, whatever you think about it, this is enough. TomT0m ^(talk) 14:39, 25 May 2014 (UTC)
Comment It is getting ridiculous. Sak4510 is a clown with one contribution only. I assume he is loud laughing about our bureaucratism. Freebase ID (P646) can be used as a link to a non-disambiguous ontology because no language conflicts are known to me. The wording is short which avoids allusions to different topics which is not the case in WMF articles linked together on a "similar as" / "related to" (redirects) WMF custom / arrogance base. gangLeri לערי ריינהארט (talk) 13:53, 25 May 2014 (UTC)

@לערי ריינהארט: Please state the facts about the user (i.e. "this is clearly a test from a user who only has one edit here") without calling them a clown. --AmaryllisGardener ^talk 18:38, 25 May 2014 (UTC)

Like TomT0m said. --AmaryllisGardener ^talk 15:23, 25 May 2014 (UTC)
Ivan, a nomination initiated with the one-word rationale "Can." is absurd and not worth discussing. Beyond that, my rationale for keeping this property is based upon Denny's comment in Wikidata:Project_chat/Archive/2013/11#Freebase-Wikidata_mappings:

The suggestion is about linking to Freebase, just as we link to IMDB, VIAF, OSM, or MusicBrainz. Bots and tools then have the possibility to integrate data from several sources. This is not about copying data from Freebase or sourcing data to Freebase, but merely about having more identifiers. Personally I think the possibility to be an authority and identity hub for the whole Web is one of the great use cases Wikidata can be, and at the same time available to anyone and free to use.
I am surprised that it is assumed that Google would have a particular benefit from having these links in Wikidata. Google has published these links, so obviously they already have them. This is about adding more keys and identifiers to Wikidata, making it a stronger hub for identity and entity reconciliation throughout the Web.
—Denny (talk) 02:00, 13 November 2013 (UTC)

If you or someone else want to have this property deleted then I recommend closing this nomination, and re-opening another a well-written rationale that takes into account Denny's comment above and the discussions in http://comments.gmane.org/gmane.org.wikimedia.wikidata/2285 and http://ultimategerardm.blogspot.com/2013/11/wikidata-freebase-interview-with-denny.html. I would likely still oppose deleting this 'Freebase identifier' property. Emw (talk) 18:20, 25 May 2014 (UTC)

Thinks for clarify. I have no interest for Sak4510 and his actions. Some time ago I reviewed IMDB, VIAF and some other. Its contain information that can be used for data verification and/or data import. I review Freebase too, but all found information was copied from Wikipedia and Wikidata by bot. Is Freebase too young or dead project maybe?... — Ivan A. Krestinin (talk) 19:50, 25 May 2014 (UTC)

Comment (continued) I want to point out that two things:

a) Is the Freebase - Wikidate relation is a "one way" issue? Are we able to create a peer to ask for new Freebase identifiers? Maybe some WD contributors are both skilled and willing to add WD related information to Freebase. Here some links:

"perfect" items with 227 GND 646 FrB 1036 DDC 1245 Omegawiki identifiers – (208 items)

items with 227 GND 1036 DDC 1245 Omegawiki but without 646 FrB identifiers – (16 items)

The second link is a point to start identifying Freebase records and adding them to WD. If necessary FrB records should be created first.

items with 227 GND 1036 but without 646 FrB identifiers shows 171.182 hits. One reason might be that Freebase is mainly related / linked to en.Wikipedia and GND is not a copy of de.Wikipedia it is a national library database. This amount of data can not be handled by crowd computing but with some maintenance / signaling conventions one could "mark" WD items which are ready to be used for semi-automatic Freebase record generation.

b) The massive import of data into WD was made with different care. While I have not found OSM properties in disambiguation page I found the following:

Wikimedia disambiguation page (Q4167410) with VIAF identifier (P214) - (17 items) for VIAF ID (P214)

Wikimedia disambiguation page (Q4167410) with GND identifier (P227) - (78 items) for GND ID (P227)

Wikimedia disambiguation page (Q4167410) with IMDb identifier (P345) – (31 items) for IMDb ID (P345)

Wikimedia disambiguation page (Q4167410) with Freebase identifier (P646) - (1127 items) for Freebase ID (P646)

Wikimedia disambiguation page (Q4167410) with author (P50) - (29 items) for author (P50)

Manual addition as a first step helps getting aware of the arriving issues:

Wikimedia disambiguation page (Q4167410) with Dewey Decimal Classification (P1036) - ~~(1 items)~~ for Dewey Decimal Classification (P1036) - fixed see history for bookmobile (Q720920)  

לערי ריינהארט (talk) 22:03, 26 May 2014 (UTC)

Wikimedia disambiguation page (Q4167410) with OmegaWiki Defined Meaning (P1245) - (0 items) for OmegaWiki Defined Meaning (P1245)

Template:FindP helps to identify the presence of some property values; the search for Freebase - using SLASHES - fails. Unfortunately there are no tools known to me to verify the backward links. I have seen a dozen of faulty links but there is no place to post them, it seems that nobody is willed to take care of them. The most evident method would be to use WD inline quality statements. No person and no bot can say it was not aware of their presence.

Regards gangLeri לערי ריינהארט (talk) 21:24, 26 May 2014 (UTC)

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

P1379 (P1379)

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

Miscreated property by click "Create" button twice accidentally; duplicate to China railway TMIS station code (P1378). GZWDer (talk) 12:58, 24 June 2014 (UTC)

Deleted --Jakob (talk) 13:20, 24 June 2014 (UTC)

P1298 (P1298)

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

Indeed. -- Gymel (talk) 21:44, 9 June 2014 (UTC)

Delete --Pasleim (talk) 01:08, 11 June 2014 (UTC)

Comment Labels and descriptions in French and English could use some work. --- Jura 11:36, 14 June 2014 (UTC)

Delete I was just going to suggest this myself. Usage: 937, 1298 Danmichaelo (talk) 23:28, 14 June 2014 (UTC)

Delete Snipre (talk) 12:18, 16 June 2014 (UTC)

Deleted --ValterVB (talk) 19:31, 5 July 2014 (UTC)

Commons category (P373)

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 strong consensus to keep this property at least for the time being. It can be nominated again when the suggested alternate ways to deal with commonscats are implemented. --Jakob (talk) 14:50, 6 July 2014 (UTC)

Can be handled via topic's main category (P910) and sitelink to Commons category. Reverse way is via P310 (P310). Procedure: 1) mark as deprecated. 2) A bot should remove all links where the commons category is linked via P910 and the sitelink there. 3) For items having P373 but no P910 a bot can move the information to P910 and if needed create an item 4) Create a report for cases where the links to commons do not agree (see example of mismatch for Aveiro District below) 5) fix the reported cases 5) P373 should be empty now, delete it..--Tamawashi (talk) 05:27, 27 June 2014 (UTC) If an article item has a topic's main category (P910) having an item that links to Commons, then data is duplicated, or worse current and outdated information is stored at the same time. Watch Aveiro District (Q210527) and Category:Aveiro District (Q8280642) which are linked twice with each other (P310/P910) and where the category item links to commons:Category:Aveiro District both link to commons:Category:Aveiro (district) via P373. The longer P373 stays, the more outdated information will be created. Tamawashi (talk) 05:27, 27 June 2014 (UTC)

Delete but not yet Unnecessary property, but I would wait till Bugzilla: 47930 is fixed, because Wikipedias are using this property and it wouldn't be nice to leave them without alternative. Bear in mind that an item can be connected with topic's main category (P910), but that doesn't guarantee that it has a Commons category.--Micru (talk) 07:19, 27 June 2014 (UTC)

Keep - the property is being used by other projects. Please read Wikidata:Properties for deletion/Header and update all the releted projects in their village pumps... Eran (talk) 10:20, 27 June 2014 (UTC)

Keep until there is a real "commonscat" link in the interwiki section, or Wikidata:Notability consensus changes and there is an user tool to create a category item with a commonscat link. Specificially:
- Creating new category items for Commons-only links would violate Wikidata:Notability: Consensus so far has been that a Commons page doesn't qualify an item for Wikidata. We'll need another RfC for this to replace the 2013 RfC at Wikidata:Requests for comment/Commons links#Addendum2.
- Commons category (P373) could be migrated to topic's main category (P910)->commonswiki, but all that data came from people who used Commons category (P373) because it's convenient. Once Commons category (P373) is deleted, will people still contribute Commons links at the same rate? Instead of the single step of just adding Commons category (P373) to an item, a user will be expected to
  1. already know that adding a Commons category link means doing everything below:
  2. create the new item;
  3. know the label standards for category items on Wikidata;
  4. add instance of (P31)->Wikimedia category (Q4167836);
  5. add category's main topic (P301) to point back to the first item;
  6. go back to the first item and add topic's main category (P910) pointing back to the new item; then
  7. go back to the new item add the "commonswiki" link everyone wanted in the first place.
  That's annoying even for intermediate users. What will really happen, instead, is that most users will just change their mind and skip it if there's not already a category item. The idea of going through 3 minutes of Wikidata's mandatory-baby-steps interface, just to add something that takes 20 seconds now, would make me just skip it half the time, and I'm not even new. Is the typical user really going to be expected to do that?
Overall, saying that a semiautomatic tool could do it in the future doesn't count for much — we should have a new RfC, and then the tool, before we deprecate Commons category (P373). --Closeapple (talk) 11:11, 27 June 2014 (UTC)

Keep - per above, you would first need to change the notability policy before you can replace this template. You would also need to fix the lookup of random items problem (bugzilla:47930). Multichill (talk) 12:56, 27 June 2014 (UTC)

Delete on principle. Let's keep things consistent. The RfC is aged forever considering the lifetime of Wikidata and a lot of things are changed. I acknowledge the usability concerns but that's a pure interface problem that should be tackled at the interface level : a default gadget will be very convenient. A Wikidata Game is also very convenient. Last but not least : let's mutualize datas beetween projects. A commonscat is linked to the same item as a Wikipedia category, we will link all the equivalent projects categories at once. So the income ill be less duplicate items and a lot of work done once for a lot of projects category pages. Commons cat is not an isolated case, it's just the case for which a link to the category is the most useful. It could also be possible to keep the property and make a bot translate the statement. TomT0m ^(talk) 15:58, 27 June 2014 (UTC)

Keep Not yet. I am one of these users, who regularry maintain Wikidata:Database reports/Constraint violations/P373. And there are many items, where two or three items have (amd should have) same link to commonscat. How to manage it without P373? People on Wikipedias wants to have link to commonscat even if this is not strictly the ame theme (random example: commons:Category:Actors_from_New_Zealand vs Category:New Zealand film actors (Q7024189) and Category:New Zealand actors (Q7097443), second random example: commons:Category:People of Graz: Category:People from Graz (Q7112432), Category:Births in Graz (Q14330709)) If there is possibility of strictly 1:1, P373 should be eliminated. But 1:1 is not possible yet. There are also many items which should be merged - and without this property should be bigger problem to find them together. Next problem: category's main topic (P301) is used in 167613 items. But 46092 of them (1/4) have not inverse topic's main category (P910). One more problem - e.g. in cswiki we now have thousands of categories which gets target value for {{Commonscat}} only from P373. And there is no knownw way how to write this value hard-coded to these pages (something like {{subst:#property:P373}}). JAn Dudík (talk) 21:39, 27 June 2014 (UTC)

Keep We had this discussion four month ago: Wikidata:Requests_for_deletions/Archive/2014/Properties/1#PfD_P373. <stroke>And {{Property for deletion}} template is not placed on the property talk page, cf. header of this page.</stroke> --Pasleim (talk) 22:31, 27 June 2014 (UTC)
Template added. TomT0m ^(talk)

Keep I do not consider P373 as permanent solution, but that permanent solution from my view is greater integration of commonscat information to the item, not smaller. Also it is necessary to have regard to 150+ templates on wikis using P373 now; most of people from wikis care about info saved at wikidata, they do not care about our internal structure.--Jklamo (talk) 10:39, 28 June 2014 (UTC)
KeepThis is a useful property, I rely do not understand what is the purpose of the deletion. Hanay (talk) 13:11, 28 June 2014 (UTC)

Delete, but only after technical ability to merge category and article to single item will be implemented. — Ivan A. Krestinin (talk) 13:47, 28 June 2014 (UTC)
Keep --Rippitippi (talk) 23:31, 2 July 2014 (UTC)
Keep per Closeapple. Sannita - not just another it.wiki sysop 22:57, 5 July 2014 (UTC)
Keep Jianhui67^{talk★contribs} 09:40, 6 July 2014 (UTC)

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

earliest date (P1319)

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 longer valid. James F. (talk) 16:24, 30 August 2014 (UTC)

(@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)

Keep until the time datatype does so. --Jakob (talk) 18:08, 21 May 2014 (UTC)
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
http://tools.wmflabs.org/wikidata-todo/autolist.html?q={{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)
Question When will "eventually" be? --- Jura 05:37, 26 May 2014 (UTC)
- Would you have at least an earliest date? --- Jura 11:58, 9 August 2014 (UTC)
Keep It has some use as qualifier of unknown dates. --Micru (talk) 08:17, 27 June 2014 (UTC)
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)
Not deleted The time datatype is in place on the property, so apart from the above discussion in favor of a keep, the request reason is no longer valid. Hazard SJ 16:43, 11 August 2014 (UTC)

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

P60 (P60)

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.

Done. James F. (talk) 16:24, 30 August 2014 (UTC)

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

After the consensus in this discussion, all statements of P60 was moved to P31 (see here). Please, I ask to an admin to delete P60 and its constraint page.--Paperoastro (talk) 16:49, 16 August 2014 (UTC)

Done --ValterVB (talk) 17:36, 16 August 2014 (UTC)

Please give a reason.--貞子的姐姐 (talk) 02:15, 28 August 2014 (UTC)

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

Dharma Drum Institute of Liberal Arts place ID (P1188)

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. James F. (talk) 16:24, 30 August 2014 (UTC)

The only reason given for creating this property was: "spilted from above". "Above" meant Dharma Drum Institute of Liberal Arts 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)

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)
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)
Comment I've added this property into a few more items. --Jakob (talk) 17:25, 28 June 2014 (UTC)
Keep --Micru (talk) 10:44, 7 July 2014 (UTC)
Not deleted There's no consensus to delete this after about 5 months, and additionally, there's no active discussion about it. Hazard SJ 14:18, 8 August 2014 (UTC)

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

P133 (P133)

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, use subclass of (P279) instead. --Pasleim (talk) 09:45, 27 September 2014 (UTC)

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

The property P133 (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 P133 (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. πr² (t • c) 23:50, 23 June 2014 (UTC)

Delete ~~part of (P361)~~ subclass of (P279) is sufficient and more useful. P133 (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)

Delete subclass of (P279) is sufficient. See Wikidata:Item classification. Tamawashi (talk) 13:45, 11 July 2014 (UTC)
Delete instance of or subclass of are enough. Snipre (talk) 11:49, 1 September 2014 (UTC)
Delete redundant with instance of (P31) and subclass of (P279). Emw (talk) 17:20, 1 September 2014 (UTC)

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

person with disabilities (Q15978181)

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 this item --Pasleim (talk) 09:45, 27 September 2014 (UTC)

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. - - (Cycn/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 ID (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

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 disability (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. disability (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 person with disabilities (Q15978181) is a "cleary identifyable concept" in the sense of WD:N but the underlying bare-bones concept is disability (Q12131). I would assert that any specific application of the concept as in person with disabilities (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 person with disabilities (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)  

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 or mythical 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 (Arabs (Q35323)), geographical (French (Q121842)), professional ranks chief officer (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)  

is famous for beeing a deaf composer. Ray Charles (Q544387)  

is famous for beeing blind. Helen Keller (Q38203)  

for beeing both. Oscar Pistorius (Q201377)  

(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 parasport (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)

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

P616 (P616)

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.

delete this property. Duplicate of P1369, but much less used. --Pasleim (talk) 09:43, 27 September 2014 (UTC)

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

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)

In these examples you see that they have the same values even from the same sources: Q3699231, Q5893091, Q5897122, Q5896881, Q10858640.--دوستدار ایران بزرگ (talk) 14:03, 24 July 2014 (UTC)

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

Datatype change: P513 (P513)

Property:P513 replaced by birth name (P1477)

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 have created birth name (P1477) and marked P513 (P513) as deprecated. If someone's willing to make a bot to change the statements with p513 to p1477, that would be great. --Jakob (talk) 00:45, 18 September 2014 (UTC)

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

Should also be replaced with monolingual-text type. See talk page..--GZWDer (talk) 10:32, 4 September 2014 (UTC)

Support. --putnik 15:59, 8 September 2014 (UTC)

Delete. I am not versed yet in the use of monolingual-text type but I have to note that many people have 2 or 3 parallel birth names (minorities that speak 2 languages etc.) so better make sure the other choise allows such an option. DGtal (talk) 06:06, 9 September 2014 (UTC)

Support -- Vlsergey (talk) 14:29, 12 September 2014 (UTC)

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

Can I ask for a greater explanation of this deletion/deprecation. There is some implicit knowledge that is not obvious, and the pointing to the article talk page is not obvious, and if the page is deleted, then it won't be obvious. — billinghurst sDrewth 03:55, 20 September 2014 (UTC)

The property documentation is missing: Can someone pleace clarify the use of this property? Right now we have two ways of using "birth name". In some languages "birth name" means maiden name (= former last name). Others use this property for the full name of a person, like Bill Clinton's birth name is "William Jefferson Clinton". Please discuss here. --Kolja21 (talk) 14:32, 20 September 2014 (UTC)

P1530 (P1530)

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

Test property and no longer used.--GZWDer (talk) 11:11, 23 September 2014 (UTC)

Done --Jakob (talk) 13:40, 25 September 2014 (UTC)

Ethnologue.com language code (P1627)

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 by proposer. Andrea Shan (talk) 01:16, 25 November 2014 (UTC)

Codes since edition 15 of the ethnologue, published 2005, are the same as ISO 639-3 Property:P220, see http://www.ethnologue.com/codes. --Andrea Shan (talk) 04:21, 24 November 2014 (UTC)

Keep but make it for pre-2009 (or better, pre-2005) "capital letter" SIL codes: ISO 639-3 is sort of a merger of ISO 639-2/T with SIL codes, but sometimes doesn't match either one. See the codes in en:Wikipedia:WikiProject Languages/Primary language names in Ethnologue 13 vs. en:Wikipedia:WikiProject Languages/Primary language names in Ethnologue 16 by ISO code. Some background:
1. The 3-letter "capital letter" (upper case) "SIL codes" started in the early 1970s and has been public since 1982. The codes were in the computer databases used for the 8th (1974) and 9th (1978) editions of the Ethnologue, but weren't actually printed in the Ethnologue itself until 10th edition (1982). These codes were used (with updates) through the 14th edition (2000). (See Simons (ISBN 978-0-08-044299-0) reference in the en:Ethnologue artice.)
2. Meanwhile, in 1989, work started on the the 3-letter ISO 639-2 codes; ISO 639-2 was first released in 1998. The SIL codes and ISO 639-2 codes do not match. (Just to drive you nuts, some of ISO 639-2 doesn't even match itself: There is a ISO 639-2/B and a ISO 639-2/T; there are 20 languages for which the /B and /T codes are different.)
3. SIL was in on the development of ISO 639-3 starting in 2002. In the 15th edition (2005), Ethnologue switched to lower-case codes that mostly matched the draft ISO/DIS 639-3, instead of the old "SIL codes". The 16th edition (2009) was the first to use full-standard ISO 639-3. ISO 639-3 apparently gave precedence to the ISO 639-2 code first, then to the old "SIL code" only if no 639-2 code existed: Simons says "hundreds of the Ethnologue language identifiers were changed in order to achieve alignment with ISO 639-2".

In summary, all three standards (ISO 639-2, ISO 639-3, capital-letter pre-2005 SIL codes) are different: Even though they all use 3-letter codes, the code is often different in one or each of them. And SIL codes were the only comprehensive codes for the world's languages until 2005-2009, as far as I know. --Closeapple (talk) 07:11, 24 November 2014 (UTC)

Keep After reading the comments by User:Closeapple I think we should keep the property. - Also: Wikidata has to stay true to the principle that any statement should be able to be made (as long as it can be sourced and is notable). And a widely used code, like in this case, is notable, even after it goes out of usage. --Tobias1984 (talk) 08:32, 24 November 2014 (UTC)

Comment See Property talk:P1627#Error in proposal. I support switching to "3 letter uppercase". The current codes are not called "SIL code". Andrea Shan (talk) 01:07, 25 November 2014 (UTC)

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

P202 (P202)

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.

After seven days there are Delete:7, Keep:0, and no other contributions. According to the rules for deletion this seems to mean "Consensus to delete, use instance of (P31) instead.". Andrea Shan (talk) 02:59, 26 November 2014 (UTC)

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

Redundant, inconsistent and thus possibly confusing readers, and needing special programming for lakes. E.g. "P31=lake and P202=crater lake" can be said directly with one statement "P31=crater lake", since a crater lake is a subclass of a lake. Actually, it is currently allowed to have "P31=crater lake AND P202=crater lake", since any user could use instance of in the specified way (rdf:Type).--Andrea Shan (talk) 02:43, 18 November 2014 (UTC)

Comment My reasoning is similar to that by User:Izno for mountain type. Andrea Shan (talk) 03:08, 18 November 2014 (UTC)

Delete. Redundant with instance of (P31). Emw (talk) 04:21, 18 November 2014 (UTC)
Delete. Per Andrea Shan. --Casper Tinan (talk) 10:10, 18 November 2014 (UTC)
Delete Per Andrea Shan and Emw. --Paperoastro (talk) 10:28, 18 November 2014 (UTC)
Delete Per Andrea Shan. -- LaddΩ chat ;) 02:25, 20 November 2014 (UTC)
Delete per above. --Jakob (talk) 22:49, 22 November 2014 (UTC)
Delete per above. --AmaryllisGardener ^talk 22:50, 22 November 2014 (UTC)
Delete per above. Jianhui67^{talk★contribs} 03:18, 25 November 2014 (UTC)

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

P1623 (P1623)

P1631=MMSI

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, duplicate of MMSI (P587) --Pasleim (talk) 10:40, 1 December 2014 (UTC)

P1623 (P1623) is a duplicate of MMSI (P587). Since the former was recently announced in the weekly update, a redirect would be sensible. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:28, 24 November 2014 (UTC)

Comment Pinging people involved in Wikidata:Property proposal/Archive/27#P1623: User:Joshbaumgartner, User:Tobias1984 -- LaddΩ chat ;) 03:12, 25 November 2014 (UTC)

Delete Better late than never. Can we redirect a property?? -- LaddΩ chat ;) 03:12, 25 November 2014 (UTC)

Delete If it is really the same identifier. --Tobias1984 (talk) 08:22, 25 November 2014 (UTC)

Delete "MMSI" (P:P1623): Same thing as P:P587, even if the formulation of the proposal wasn't ideal. --- Jura 13:28, 30 November 2014 (UTC)

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

P766 (P766)

P766=event location

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.

About 9 month of discussion, Consensus is reached to delete.. --DangSunM (talk) 03:24, 7 December 2014 (UTC)

Now that we have ranks and qualifiers using P766 (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.

Notified participants of 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)

Keep P766 (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, 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)

Delete -- Lavallen (talk) 07:37, 30 March 2014 (UTC)

Delete per Zolo. Mushroom (talk) 09:39, 7 April 2014 (UTC)

Delete harmful. TomT0m ^(talk) 10:22, 7 April 2014 (UTC)

Delete --Marsupium (talk) 12:53, 11 April 2014 (UTC)

Keep Location is constitutional for (most) events but by definition ephemeral for movable objects. I can imagine an extension of P766 (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 location (P276) also. -- 93.232.230.6 22:43, 11 April 2014 (UTC)

Some event-items could use time qualifiers (say: Foire Internationale d'Art Contemporain (Q653038): Paris Expo Porte de Versailles (Q3364319): 1999-2005, Grand Palais (Q457318): since 2006). And sometimes, large buildings are moved (Temples of Abu Simbel (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 (Temples of Abu Simbel (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)

Delete I assume that P766 (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)

Delete. per the discussion above. Filceolaire (talk) 00:31, 25 April 2014 (UTC)

Comment If P766 (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)

Keep. Renaming P766 (P766) is a prerequisite to deleting this one. Circeus (talk) 23:04, 6 May 2014 (UTC)

Comment TO CLOSING ADMIN: See below where Circeus wrote in response to Emw: "I must say I agree with that idea, assuming moving properties over can be done automatically". Since Circeus only has 13 live edits since end of May, it might be difficult to get him here to clarify whether this means he changed his opinion but just didn't change the "official" vote. To me it looks like that. User:Pasleim, you closed some requests here, what do you think? Andrea Shan (talk) 10:10, 5 December 2014 (UTC)

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 location (P276) has the lower Property ID, wouldn't it make sense to relabel that property to 'location', and delete P766 (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:

Support — Felix Reimann (talk) 06:49, 16 May 2014 (UTC)

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 http://www.w3.org/TR/owl-guide/#PropertiesOfIndividuals. Per that OWL note, I'll plan to mark the updated location (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 P766 (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 P1134 (P1134). I can't see any difference. --Zolo (talk) 04:57, 29 May 2014 (UTC)

P766 (P766) is used on 4500 to 5000 pages. location (P276) is used on 1000 to 1500 pages. P1134 (P1134) is used on 5000 to 5500 pages so keeping P276 means we have a lot of cleaning up to do but I support combining these three properties.

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 Chinese Communist Party (Q849418) is valid for Russian language, but Xi Jinping (Q15031) <location> General Secretary of the Chinese Communist Party (Q849418) is invalid. Russian-language users will use property named "место" for claims like Xi Jinping (Q15031) <место> General Secretary of the Chinese Communist Party (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 Chinese Communist Party (Q849418) is also valid in English while Xi Jinping (Q15031) located in General Secretary of the Chinese Communist Party (Q849418) is not. (The preferred property there is Xi Jinping (Q15031) position held / занимаемая должность (P39) General Secretary of the Chinese Communist Party (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)

Thank you Ivan A. Krestinin and thank you Emw for clarifying this. Ivan; We have similar problems in English which is why we have ridiculously long labels like P132 (P132). If "место" can be interpreted in 2 ways then I guess you will need a longer label in Russian - like "место (use for physical place. Use P39 for office held)." Just as the English label for Q44148 is "Male animal" to distinguish it from male (Q6581097). I still say we should merge these properties. Filceolaire (talk) 23:42, 2 November 2014 (UTC)

Keep There are lingual differences between where something is and where something happend in many languages making labeling a merged property difficult and unclear. I also use P1134 (P1134) and location (P276) for different purposes in the same object. /ℇsquilo 12:25, 8 August 2014 (UTC)

ℇsquilo; Can you give us an example of an item where you have used P1134 (P1134) and location (P276) for different purposes? Filceolaire (talk) 23:43, 2 November 2014 (UTC)

Treasury of Sweden (Q9337727) /ℇsquilo 07:52, 3 November 2014 (UTC)

ℇsquilo You say that Treasury of Sweden (Q9337727) is location (P276)Stockholm Palace (Q750444) and P1134 (P1134)Gamla stan (Q579854) where Stockholm Palace (Q750444) is also P1134 (P1134)Gamla stan (Q579854). I still don't see the need for a different property for these two though I see that the label for P1134 in Swedish is more like "Located in the locality / neighborhood / etc." than the English label. I still see why you can't use the same property to say 'famous paintinglocated in 'art gallery' which is located in 'central square' located in 'old town' located in 'central borough'. You have arrived at the smallest administrative entity so you switch and use {{P|131} for the continuation up to 'the city', 'Central region' and 'Country'. You have not convinced me to change my vote. Filceolaire (talk) 00:59, 26 November 2014 (UTC)

Delete support User:Emw merge into location (P276) and rename that to "location". Andrea Shan (talk) 02:49, 26 November 2014 (UTC)

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

type of administrative territorial entity (P132)

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.

About 1 year of discussion I decided to close. Consensus is to delete. by 12

Keep and 16

Delete. now we should use instance of (P31). --DangSunM (talk) 03:16, 7 December 2014 (UTC)

For the record: Actually 17

Delete, one user wrote "vote replace with instance of (P31)" which has the same effect. Frank Robertson (talk) 16:33, 7 December 2014 (UTC)

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

First, "place the {{Property for deletion}} template on the property talk page. Then, open the discussion on this page", cf. header of this page. --Zuphilip (talk) 12:08, 7 December 2013 (UTC)
As far as I am informed Dexbot is removing (replacing) P107 statements. Can you elaborate more why you think this property should be deleted? To save one statement does not sound very convincing. Besides I think there are some good reasons for this property. --Zuphilip (talk) 12:32, 7 December 2013 (UTC)
See RfD for P60 above.--GZWDer (talk) 12:38, 7 December 2013 (UTC)
Sorry, but I still don't see the historical steps. Dexbot was started after the discussion here Wikidata:Project_chat/Archive/2013/11#Report_and_questions_on_migrating_away_from_P107: "When there are any of [P60, P132, P202], create a P31 claim of the same value and delete the P107 value". Now, you want to delete the properties on which this bot is based on? --Zuphilip (talk) 15:16, 7 December 2013 (UTC)
Comment This property P132 (P132) is heavenly used in the Wikidata:Country_subdivision_task_force. The main porpose of this property is IMO to point at the actual administrative level. For example the administrative subdivision of Germany is rather complex: de:Datei:Administrative_Gliederung_Deutschlands.svg. The value of P132 of an administrative division is its "level", where there are also "multi-level" objects as independent city of Germany (Q3559083) or statutory city of Austria (Q262882) in Austria. These objects have in addition often several values connected by instance of (P31) (which is for P60 AFAIK not the case). Can you select the right one out of the P31-claims without looking at the P132 claim? Have for example a look at Aalen (Q3951), Linz (Q41329). Moreover, we can deal with Ortsgemeinde (Q692680), market municipality (Q562061), place with town rights and privileges (Q13539802) in P31 and still always use municipality in Germany (Q262166) as value for P132. One can create accurate queries by using the property P132 (P132) together with the properties located in the administrative territorial entity (P131) and contains the administrative territorial entity (P150). --Zuphilip (talk) 15:16, 7 December 2013 (UTC)
The closest you can get a "kreisfrei stadt" in Sweden can be found in Gotland Municipality (Q374794). It is described as both a "P132:kommun" and "P132:landsting" in this case. The difference is that it looks like the term "kreisfrei stadt" ("landstingsfri stad") has not been used in the Swedish language for maybe 100 years, but it's partly the same kind of concept. Another difference is that a "landsting" (County counsil) is difficult to describe as a geographic entity. -- Lavallen (talk) 16:12, 7 December 2013 (UTC)

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 in 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)
~~Keep~~ 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)
~~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)

Delete Time is changing, opinions too. Having a generic property like P31 has some drawbacks but it will simplify a lot if we get rid of this last "type"-property. --Pasleim (talk) 01:56, 18 July 2014 (UTC)

That's true of P132 also. --Izno (talk) 16:33, 8 December 2013 (UTC)

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)

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)
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)

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)

P132 (P132) municipality in Germany (Q262166)

instance of (P31) Greater district town (Q448801), city (Q515), district capital (Q134626), medium regional center (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 Greater district town (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'. Greater district town (Q448801) seems like the most appropriate P31 value, since it's a subclass of municipality in 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 P132 (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 P132 (P132) fulfill the statement 'subclass of administrative subdivision'. There's a better way to do that: use http://tools.wmflabs.org/wikidata-todo/tree.html?q=Q56061&rp=279&lang=en 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 medium regional center (Q1401585). This cannot be deduced from the population size as this is a term from the German urban studies and planning (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 Greater district town (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 place 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 medium regional center (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)

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)
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)
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 medium regional center (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)

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)
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- 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)
Delete and replace with instance of (P31). — TintoMeches, 17:48, 6 January 2014 (UTC)
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) P132 (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 https://www.wikidata.org/w/index.php?title=Wikidata:Database_reports/Constraint_violations/P132&action=history . 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)

Keep until there is an acceptable migration path. --80.114.178.7 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)
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)
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)
Delete 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)
Keep:P31 is no alternative, following Pasleim and Holger--Oursana (talk) 08:43, 28 February 2014 (UTC)
- Comment Oursana, Pasleim changed to "delete". 91.9.124.129 04:45, 24 November 2014 (UTC)
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)
Keep All discussion before show that we need to keep that property. --Dom (talk) 19:51, 15 March 2014 (UTC)
Keep GerardM (talk) 07:27, 21 March 2014 (UTC)
Delete, per Emw, me. For consistency in the datas mostly. TomT0m ^(talk) 14:14, 29 March 2014 (UTC)
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)
Delete per Emw and Lavallen. Mushroom (talk) 09:32, 7 April 2014 (UTC)
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)
Keep makes the geographic structure easy to identify and maintain. ----- Jura 15:29, 10 May 2014 (UTC)
Keep Not everything can be altered with P31. — by Revi_complaint? at 10:31, 3 August 2014 (UTC)
Delete Thomas11 (talk) 11:54, 27 October 2014 (UTC)
Delete Redundant. Vladimir Gribochev (talk) 00:05, 3 November 2014 (UTC)
Delete, after some practice, the redundancy does not appear practical. One reason I was a bit reluctant to use P31 here is that tP31 is apparently assumeed to represent a stable feature of the item while administrative status changes with time, but using a different property for that does not appear to do any good. --Zolo (talk) 06:47, 7 November 2014 (UTC)
Comment As of today there are 20 delete (incl. 1 replace with P31) and 12 keep. Some original "keep" have been changed by the respective users to "delete", e.g. see User:Pasleim and User:Paperoastro (stroke and voted further down). Could User:GerardM review and maybe clarify his keep? 91.9.113.132 04:52, 24 November 2014 (UTC)
- If my opinion concerning this procedure is not clear, here I confirm my Delete. A question: is it possible to transform this property in "subproperty" of P31, when statement of property will be available? --Paperoastro (talk) 08:59, 25 November 2014 (UTC)

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

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 was deleted, no more discussion here needed. --Stryn (talk) 10:17, 24 December 2014 (UTC)

New Proposal

I voted above to Keep P132 (P132). I think that for every instance of P132 (P132) we should add the statement instance of (P31):administrative territorial entity (Q56061) to that item. This would give us the generic statement using instance of (P31) as well as the specific statement using P132 (P132). Filceolaire (talk) 23:17, 2 November 2014 (UTC)

Saying that an item is a "province of Russia", whilst "province of Russia" is a subClassOf "administrative entity" implies that the item is an "administrative entity". That is the core of classification. Vladimir Gribochev (talk) 00:05, 3 November 2014 (UTC)

But I'm not saying someplace is instance of (P31)'province of Russia'. I'm say it is instance of (P31)'administrative entity' and P132 (P132)'province of Russia'. The reason for doing this is so the hierarchy of 'administrative entities' is kept separate from all the other things which a 'province of Russia' might be an instance of (P31) Filceolaire (talk) 00:30, 26 November 2014 (UTC)

User:Filceolaire I don't know what Vladimir meant with a "province of Russia" and what that would be. But if there is an item that has "type of adm. entity=province of Russia", then it should also have "instance of=province of Russia". "instance of" should be as precise as possible, that is done so for mountains, lakes, ships, cars .... I don't know why you want to keep the "hierarchy of administrative entities" separate and what that would be. "New York State" Q1384 is an instance of a U.S. state. P132 and P31 have exactly the same value. P31 could also have "entity that has a name start with the letter N." Then instanceOf contains other data than "administrative hierarchy" but the administrative hierarchy is still there. "US state" is in the subclass tree for administrative territorial entities. "entity that has a name start with the letter N." is not, since a natter is not an administrative entity, but starts with N (in English).

If P31 and P132 are filled correctly, then the P132 values will for every item also exist in P31. Duplication increases maintenance work. Every edit in P132 also has to be done in P31. Andrea Shan (talk) 07:46, 26 November 2014 (UTC)

Andrea Shan: humans are all identified as "instance of:human" not "instance of"football player" or "instance of:politician" or "instance of:U.S.citizen" or "instance of:person born in Malta" so it is incorrect to say that 'instance of' is always as precise as possible. If that were so then there are a lot of other properties which could also be replaced by 'instance of' - properties like "genre" for instance which is used with "instance of:novel" and "instance of:film" and other types of creative work to add precision. Filceolaire (talk) 19:15, 2 December 2014 (UTC)

User:Filceolaire: Thanks a lot for pointing me to this error I made! My statement was wrong. I am now thinking about the difference. The subclasses for humans that you mentioned can all be described by the class human and a few additional properties - and no more. A U.S. state, a province of Russia, a province of Spain, a province of Canada cannot be described that easy. They are all organizational units that claim some relation to a specified territory. They can differ in official designation (state/province...), how the head -if any - is selected (appointment, election), what functions/rights they have, .... One could also ask whether there is a single "instance of" claim or several. Some administrative entity items have several, but most have one. Those that have several could in some cases be split, e.g. if the only reason for having it combined is coincidence of boundaries, like in some English Wikipedia articles, e.g. several islands and administrative entities are combined. Do you think that could be an important difference - the number of properties that can be attached to a class (human/administrative entity) to describe the subclass (politician, U.S. citizen/ province of Spain)? Andrea Shan (talk) 02:26, 4 December 2014 (UTC)

Due to request on my user talk page, I will reopen to discuss the new proposal. however, P132 (P132) will going to delete for sure.--DangSunM (talk) 15:09, 7 December 2014 (UTC)

User:분당선M - the "new proposal" was started by a user that voted Keep. No one else supported the new proposal, the only other that talked opposed it. The user that asked for reopening is also one that voted Keep. I think if they want a new property they should seek another venue. Also the reasoning by the reopen requester "It's not even sure that people who voted once are still active user or haven't changed theirs minds." can be taken for both directions. Even more, since two voters switched from Keep to Delete, it could be argued that more would switch in the direction of Delete. I propose to re-close so that the whole thread can be properly archived, otherwise it may stay here for another year. Frank Robertson (talk) 10:42, 13 December 2014 (UTC)

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

number of platform tracks (P1103)

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) 17:53, 21 December 2014 (UTC)

Replace with has part(s) (P527) => railway platform (Q325358) with quailfier quantity (P1114). This is the generic method of describing how many parts of something an object has. /ℇsquilo 08:48, 8 August 2014 (UTC)

Keep, now I can query the value using simple construction: {{#property:P1103}}. Is there so simple way to query value in suggested case? Railway station contains many thinks except platforms (ways, buildings and etc.). But we have information about platforms and ways only for the most stations. It is bad situation use has part(s) (P527) property with incomplete lists. Something like human (Q5) <has part(s) (P527)> toe (Q154425) and ear (Q7362). — Ivan A. Krestinin (talk) 21:08, 9 August 2014 (UTC)

Keep. As I read the description of has part(s) (P527), it is the opposite of part of (P361). That means that number of platform tracks (P1103) cannot be replaced by has part(s) (P527) as that would mix instances of a railway stations with the generel concept of perrons. For instance you cannot say <Copenhagen Central Station (Q1495052) has part(s) (P527) railway platform (Q325358) quantity (P1114) 13>, because you would not claim <railway platform (Q325358) part of (P361) Copenhagen Central Station (Q1495052)>. So this proposal would radical change how another property is used without discussion of this first. I do not oppose to replacing several <number of something> properties into one, but the proposal must provide a good replacement. Regards, Dipsacus fullonum (talk) 13:54, 10 August 2014 (UTC)

Using the paradigm described by the keep-voters would imply that we need an abundance of "number of ..." properties like "number of gun barrels" for weapons, "number of pylons" and/or "number of arcs" for bridges, "number of hardpoints" for aircraft, etc, etc. Better then to use the generic method described in the delete-proposal. /ℇsquilo 12:17, 11 August 2014 (UTC)

@Esquilo:: I really do not understand your comment. The two keep-voters above use very different arguments, and if you read my vote above you will see that I would not like to see an abundance of "number of ..." properties, but that I do not think that the proposed replacement is good. But come with a better replacement, and I am likely to support you. Regards, Dipsacus fullonum (talk) 13:01, 11 August 2014 (UTC)

As I understand it, Ivan wants to keep this property because it is easier to make queries. A vaild point, but a quite weak one. He also says it is bad with incomplete lists of has part(s) (P527). I think that is inevitable. You want to keep this property because you say "you can not use has part(s) (P527) that way without violating the constraints". First of all I believe that constraint is wrong. Copenhagen Central Station (Q1495052) definitly has parts that are railway platform (Q325358). Secondly, Wikidata:Database reports/Constraint violations/P527 numbers over ten thousand, and so does the constraint violations of most well-used properties. Does anyone care about constraints anyway? If the constraints was enforced by the GUI it would be a different matter, but "inverse" constraints can not be enforced because one of them have to be added first. Furthermore, this boils down to two paradigms: Using one or a few generic propreties with qualifiers to build the structure of Wikidata. Or creating a new property for every need. The first paradigm means number of cylinders (P1100) and number of platform tracks (P1103) will have to go. The second paradigm means we can keep them. The second paradigm also means we have to create lots of similar properties. I can see two arguments for the first paradigm. First, the biggest obstacle for me when entering data into Wikidata is that I don't know what properties there are that I can use for the data I have. Even more properties won't make it any easier. Second, for every statement like "this item has a number of X" there will in most cases not exist any property "number of X", but there will almost certanly exist an item about X. /ℇsquilo 11:10, 15 August 2014 (UTC)

@Esquilo:: I do not talk about constraints as checked by bots (I do think these are very useful, but they are in no way authoritative). I talk about what is stated on each property's talk page about their intended usage. And you propose here to change the significance of has part(s) (P527). I think that it is bad idea to do that, as that would mean that the property would suddenly have two different ways to be used. Instead , I would prefer a new property designed to replace the <number of something> properties. And before one exists, I cannot support deletion of these. Regards, Dipsacus fullonum (talk) 13:28, 15 August 2014 (UTC)

@Esquilo: I think Dipsacus fullonum's point is that we should not use <Copenhagen Central Station (Q1495052) has part(s) (P527) railway platform (Q325358)> because platform is a class rather than a concrete object and -relatedly- there can be instances of platforms outside Copenhagen station. That may be a trick question abut part of (P361) that would deserve wider discussion than this deletion proposal. --Zolo (talk) 13:24, 4 September 2014 (UTC)

Keep per Dipsacus fullonum. — revi ^{^} 07:25, 9 November 2014 (UTC)

Delete per proposer. Filceolaire (talk) 14:08, 9 November 2014 (UTC)

Keep per 3 {{Keep}}ers above, P527+1114 could be unfair for dozens of East Asian stations. --Liuxinyu970226 (talk) 03:11, 12 November 2014 (UTC)

Keep it's important to say a station has <number of platform tracks (P1103) 0>, but il would be very weird to have <has part(s) (P527) quantity (P1114) 0>. So keep this propertu very useful for infoboxes. Kvardek du (talk) 22:42, 12 November 2014 (UTC)

Keep: "number of platforms" (P:P1103): per Ivan. --- Jura 13:28, 30 November 2014 (UTC)

Keep can use on many Korean train station--DangSunM (talk) 03:21, 7 December 2014 (UTC)

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

number of cylinders (P1100)

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 --Stryn (talk) 10:44, 22 December 2014 (UTC)

Replace with has part(s) (P527) => cylinder (Q245656) with quailfier quantity (P1114). This is the generic method of describing how many parts of something an object has. /ℇsquilo 08:53, 8 August 2014 (UTC)

Keep, same as number of platform tracks (P1103). — Ivan A. Krestinin (talk) 21:09, 9 August 2014 (UTC)

Keep. Same argument as my argument to keep number of platform tracks (P1103) now. I may support a proposal giving a better alternative. Regards, Dipsacus fullonum (talk) 13:58, 10 August 2014 (UTC)
Delete per Ivan A. Krestinin. Filceolaire (talk) 22:51, 2 November 2014 (UTC)
Keep: "number of cylinders" (P:P1100): per Ivan. --- Jura 13:28, 30 November 2014 (UTC)

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

pseudonym (P742)

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) 17:56, 21 December 2014 (UTC)

We have more common monolingual nickname (P1449) which include pseudonyms of people. --putnik 12:59, 12 September 2014 (UTC).--putnik 12:59, 12 September 2014 (UTC)

Comment Than we have to rename P1449 first. A nickname is if I call you "Putty". A pseudonym is something else. --Kolja21 (talk) 16:19, 12 September 2014 (UTC)

I agree that nickname and pseudonym are two dirfferent concepts. Enough different to have separate properties. On the other hand, a change of pseudonym (P742) to a monolingual text instead of string would be a desirable progress.--Shlomo (talk) 19:29, 13 September 2014 (UTC)

Question Are either of these distinct enough from the "also known as" / "aliases" field at the top of the page? GPHemsley (talk) 14:36, 16 October 2014 (UTC)

The main function of aliases is for searching on Wikidata. The main function of properties is for structuring information. They can also be used in infoboxes on Wikipedia (or other Wikimedia projects). Bever (talk) 04:21, 28 October 2014 (UTC)

Keep. A nickname is not the same as a pseudonym. We also need stage name (Q1055303), pen name (Q127843), professional name (Q11415657), art name (Q39646) and nom de guerre. Filceolaire (talk) 13:51, 9 November 2014 (UTC)

Keep "pseudonym" (P:P742): not the same as "nickname" P:P1449. --- Jura 13:28, 30 November 2014 (UTC)
Keep Agree that a pseudonym is a very specific type of name separate from nickname (P1449). Sweet kate (talk) 23:40, 13 December 2014 (UTC)
Keep Agree. Maybe pseudonym (P742) should be subproperty of (P1647) of nickname (P1449). --Chris.urs-o (talk) 06:54, 21 December 2014 (UTC)

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

P198 (P198)

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) 10:10, 26 December 2014 (UTC)

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

Redundant with "manufacturer" Property:P176..--Andrea Shan (talk) 02:32, 25 November 2014 (UTC)

Comment Next to "ship class" which is redundant with "instanceOf", "ship builder" is redundant with "manufacturer". Pinging creator and sole proposer : User:Danrok. Andrea Shan (talk) 02:34, 25 November 2014 (UTC)

Keep "ship builder" may be redundant with "manufacturer", but "ship class" is definitly not redundant with "instance of". The now deleted property P228 (P228) (watercraft type) was, but vessel class (P289) is not! /ℇsquilo 07:36, 26 November 2014 (UTC)
User:Esquilo, you probably want to make that comment above. !Voting to keep this property doesn't make sense with your comment. --Izno (talk) 00:06, 27 November 2014 (UTC)
Thanks fot the heads-up, Izno. I cancel my vote. /ℇsquilo 08:34, 27 November 2014 (UTC)
Delete, per Andrea Shan. Emw (talk) 04:35, 28 November 2014 (UTC)
Keep "ship builder" (P:P198): "builder" is more appropriate than "manufacturer" for ships. --- Jura 13:28, 30 November 2014 (UTC)
Where is the proof for that bogus claim? P176 reads "main manufacturer of this product (excluding sub-contracted manufacturers)". Does User:Jura1 care to specify what with P176 is less appropriate for ships that P198? Andrea Shan (talk) 15:17, 30 November 2014 (UTC)

This is an English problem, not a conceptual problem. This is no fondamental difference between builder or manufacturer. In other languages this difference doesn't exist. And wikidata works with concept not with English grammar. Snipre (talk) 17:06, 22 December 2014 (UTC)
Keep Property necessary for WP infoboxes. Rather make it subclassOf manufacturer (P176) when that relation becomes available. -- LaddΩ chat ;) 03:26, 1 December 2014 (UTC)

@Laddo: A ship infobox could simply use the value "manufacturer"-value from the ship item in Wikidata, couldn't it? Andrea Shan (talk) 23:43, 3 December 2014 (UTC)

Delete, per Andrea Shan. Casper Tinan (talk) 11:19, 1 December 2014 (UTC)
Delete seems redundant with "manufacturer" to me. Michiel1972 (talk) 13:36, 8 December 2014 (UTC)
Delete redundant as above. --Stryn (talk) 10:39, 22 December 2014 (UTC)
Delete Redundant. Snipre (talk) 17:06, 22 December 2014 (UTC)
Delete Jianhui67^{talk★contribs} 09:55, 25 December 2014 (UTC)

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

merge narrative location (P840) and filming location (P915)

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 --Pasleim (talk) 12:46, 22 December 2014 (UTC)

I think narrative location (P840) and filming location (P915) can be combined without any problem, rename property P840 in a generic location of the creative work (or something). The property can than also be used for other creative work items (location shown by a painting) Michiel1972 (talk) 10:07, 13 December 2014 (UTC)

"filming location" is where the film was made. Example: Toronto. The "narrative set in" could be New York or Gotham City. --- Jura 11:18, 13 December 2014 (UTC)

Keep "narrative set in" and "filming location" can have different values, and for non-film items, e.g. books, there is no filming location, but there can be a location of the narrative. Frank Robertson (talk) 12:04, 13 December 2014 (UTC)

Keep narrative location (P840) can be a fictonal location, filming location (P915) is always a real place, it is the place were the creative work was created. --Fralambert (talk) 02:30, 14 December 2014 (UTC)
Maybe the Dutch label should be changed: it's currently "locatie van film". --- Jura 08:51, 14 December 2014 (UTC)
I think filming location (P915) should be renamed to "created at".--GZWDer (talk) 11:25, 21 December 2014 (UTC)
- That would change the meaning and to express the same as before one would need qualifiers. Anyway, this properties is a good example of mess: where is "cut at", "cut by", "filmed by", "financed by"...? 91.9.110.153 02:15, 22 December 2014 (UTC)

Ok, at least I understand now the difference. A merge as asked may not be needed. Maybe P915 can change of name in Dutch into 'filmlocatie' to be more clear. I guess this pfd can be closed for now. Michiel1972 (talk) 11:53, 22 December 2014 (UTC)

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

Wikidata:Properties for deletion/Archive/2014

Contents

Property:P54 (member of sports team)

Property:P1089

Taxonomic rank properties

visitors per year (P1174)

P295 (P295)

P1205 (P1205)

Commons gallery (P935)

Commons category (P373)

P173 (P173)

P1169 (P1169)

scheduled service destination (P521)

P60 (P60)

Freebase ID (P646)

P1379 (P1379)

P1298 (P1298)

Commons category (P373)

earliest date (P1319)

P60 (P60)

Dharma Drum Institute of Liberal Arts place ID (P1188)

P133 (P133)

person with disabilities (Q15978181)

P616 (P616)

Datatype change: P513 (P513)

P1530 (P1530)

Ethnologue.com language code (P1627)

P202 (P202)

P1623 (P1623)

P766 (P766)

type of administrative territorial entity (P132)

New Proposal

number of platform tracks (P1103)

number of cylinders (P1100)

pseudonym (P742)

P198 (P198)

merge narrative location (P840) and filming location (P915)

Navigation menu

Wikidata:Properties for deletion/Archive/2014

Property:P54 (member of sports team)

Taxonomic rank properties

Datatype change: P513 (P513)

type of administrative territorial entity (P132)

New Proposal

merge narrative location (P840) and filming location (P915)

Navigation menu

Search