Wikidata:Properties for deletion/Archive/2013/3

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

contains the administrative territorial entity (P150)

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 dragging out for far, far too long, it's clear that there's not a consensus for deleting this. If anything, there's a weak consensus for keeping it. Sven Manguard Wha? 07:49, 6 September 2013 (UTC)

contains the administrative territorial entity (P150): (delete | history | links | entity usage | logs | discussion) Completely redundant as reciprocal of located in the administrative territorial entity (P131) and related properties. --Ricordisamoa 17:53, 26 May 2013 (UTC)

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

Watercraft type

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.

Closed as clear consensus to delete. I'll see about bugging someone to make the switch. --Izno (talk) 23:35, 3 September 2013 (UTC)

P288 (P288): (delete | history | links | entity usage | logs) Redundant to subclass of (P279). See this discussion Wikidata:Properties_for_deletion#Property:P289. Danrok (talk) 15:10, 30 May 2013 (UTC).

 Delete (just like other "type of ;). --Zolo (talk) 16:32, 30 May 2013 (UTC)
 Keep makes it easier to populate the related infobox field. --  Docu  at 18:08, 2 June 2013 (UTC)
 Delete. P288 (P288) is not like other "type of" properties as it is a super class of the ship types and is redundant as we can follow vessel class (P289) to the level above to see what watercraft type type a ship class is. Here we are defining a hierarchy of items so using a consistent property like subclass of (P279) makes sense. As it is only needs to be used on ship classes, not on ships, therefore it is used on many fewer items than vessel class (P289) so making it easier to use is not quite so important.
vessel class (P289) is used on every ship so we need it to be easy to use so it makes sense to have a "type of" property for this. Later we can get the devs to add a facility to define vessel class (P289) as a subproperty of instance of (P31). Filceolaire (talk) 22:37, 5 June 2013 (UTC)
 Delete Redundant with subclass of (P279). Emw (talk) 00:53, 6 June 2013 (UTC)
 Delete, per above. --Ricordisamoa 00:10, 15 June 2013 (UTC)
 Delete - Really seems more like a top-down relation for which we have "subclass of". --Tobias1984 (talk) 19:18, 15 June 2013 (UTC)
 Keep --Nightwish62 (talk) 16:53, 24 June 2013 (UTC)
instance of (P31) (i.e., rdf:type) can be used more than one on an item, though it's generally best to keep the number of such claims as close to one as possible. Cases like USS Inchon (Q5366216) instance of Iwo Jima-class amphibious assault ship (Q373197) and instance of Iwo Jima-class amphibious assault ship (Q373197) are an example of how Wikidata's type hierarchy can be a directed acyclic graph (DAG), with one item being an instance of multiple types. (Please note that this does not justify the classic misuse of P31 as a catch-all property that can support any claim.)
Esquilo, could you explain your claim that "the diversity of items pointed to by instance of (P31) would be unmaintainable without them"? Could you point me to an example of any other Semantic Web implementation having maintainability problems caused by widespread use rdf:type? Emw (talk) 00:10, 26 June 2013 (UTC)
Pretty much everyone the size of Wikidata without a stringent data model. Wikidata does not have a stringent data model, this page is a living proof of it. Considering DAG, the concept is not usable on Wikidata. Imaging deleting all taxonomical properties (like P71 (P71), P74 (P74), P77 (P77) etc) and using only instance of (P31). Such data model would be useless on other Wikimedia projects. P288 (P288) and vessel class (P289) fulfills the same purpose for ships as P71 (P71), P74 (P74) do for animals. /Esquilo (talk) 08:34, 27 June 2013 (UTC)
Deleting all taxonomical properties? Exactly that's what we are about to do once queries are properly implemented. —★PοωερZtalk 11:10, 27 June 2013 (UTC)
If the same information can be readily available using another, not yet implemented feature, it is great. But until "queries" are implemented and P288 (P288) is replaced with "queries" in all items, it should be kept. Once "queries" are implemented, we can bring up this discussion again. /Esquilo (talk) 13:46, 27 June 2013 (UTC)
Then you propose a massive amount of work later, just so we can use Wikidata now in Wikipedia. That's a bad idea, start using data in Wikipedia later instead. And all this mess because the devs were so overhasty to start phase II before it was ready... —★PοωερZtalk 14:41, 27 June 2013 (UTC)
I agree on the hasty bit, but nevertheless, phase II is live. I am also a bit concerned about the long run usability of Wikidata. Almost every step in the progeress of Wikidata seams to lessen the usability of Wikidata for other projects like Wikipedia by making the access of information more complicated. /Esquilo (talk) 10:49, 1 July 2013 (UTC)
 Delete --Nightwish62 (talk) 08:34, 17 August 2013 (UTC)
 Delete on the basis that this ship is an instance of (P31) of frigate (Q161705), and frigate (Q161705) can be defined as subclass of (P279) of watercraft (Q1229765). This would mean that all watercraft-type items need to be subclass of (P279) of watercraft (Q1229765). This would mean extra footwork for the code which fills in infoboxes on wikipedia, but that must surely be doable. It's nothing out of the ordinary. Danrok (talk) 17:19, 30 August 2013 (UTC)
 Comment Isn't 7:2 still not enough to finally delete this property? No ones here feels responsible. The whole concept of RfP doesn't work. More than three month for a single RfP request is a shame. --Nightwish62 (talk) 21:16, 3 September 2013 (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. A summary of the conclusions reached follows.

No consensus for deletion. Ajraddatz (Talk) 01:39, 2 September 2013 (UTC)

pseudonym (P742): (delete | history | links | entity usage | logs | discussion)

  • Unapropriate datatype.
 Delete The original proposal as Monolingual Text has been changed during the discussion to String and so was the property created.
IMHO the datatype should be Multilingual Text to enable transcriptions. E.g. Avrohom Yeshaya Karelitz (Q543442) should have pseudonym (he:חזון איש, ru:Хазон Иш, pl:Chazon Isz, en:Chazon Ish, etc.)--Shlomo (talk) 21:34, 5 August 2013 (UTC)
Then the property should be in monolingual text, instead of string. Strings are for language independent values, such as ISBN. --Wylve (talk) 09:37, 25 August 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.


part of the series (P179)

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

 Not deleted - consensus is clearly in favor of keeping.--Jasper Deng (talk) 19:39, 7 September 2013 (UTC)

part of the series (P179): (delete | history | links | entity usage | logs | discussion) There is more generic Property:P361 and pair Property:P527 for same purpose. --EugeneZelenko (talk) 14:24, 20 June 2013 (UTC)

This may work, but the purpose is not exactly the same. Arguably all of these items are a part of Star Wars. There is potentially for going so generic that the data becomes unusable due to vagueness. Danrok (talk) 20:16, 21 June 2013 (UTC)
Wikimania is a series of events, of which Wikimania Hong Kong 2013 is a member, but that is not the only set in which it is included. Attack of the Clones is a member of the Star Wars series of films. Fade to Black is (the last) member of The Sopranos television series. The first member of the series of whole numbers is "0". Not all series are finite, but all are countable, composed of discrete elements in an ordered set. While they may need better documentation, it is not at all clear whether these properties can all serve the same purpose. LeadSongDog (talk) 20:04, 28 June 2013 (UTC)
  •  Keep This property does not work like Property:P361 or Property:P527. Some elements can be part of more than one thing, and such things cannot necessarily be a series. This property is intended to roganize all elements closely related between them beyond a simple conection, which is "part of" means. — ΛΧΣ21 22:49, 21 July 2013 (UTC)

Could you please document your conclusions here ? Help:Modeling#Series_and_sequences It's what the page is intended to do, and could serve as a reference if we want to. We need a good documentation for cases like that, which are plenty. TomT0m (talk) 13:21, 6 August 2013 (UTC)

  •  Keep Frankly, I'm becoming infuriated by this desire to pare down the number of properties to as small a number as possible, at the cost of clarity, functionality, and ease of use. There is a "series" field in the much used Infobox video game template, and I'm sure it's used in other infoboxes as well. If the point of Wikidata was strictly to record information, without paying attention to how that information is/was intended for use, your proposal might have merit. The fact of the matter though is that part of Wikidata's intended use is to support Wikipedia infoboxes by centralizing the information, field by field, on Wikidata. Every time we yank an existing field in the name of blind efficiency, we make it that much harder for Wikidata to be used constructively. Sven Manguard Wha? 07:33, 6 September 2013 (UTC)
  •  Keep --Nightwish62 (talk) 11:01, 6 September 2013 (UTC)
  •  Keep They seem to have discrete purposes. NativeForeigner (talk) 19:35, 6 September 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

given name (P735)

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

 Not deleted as consensus was not reached, at least not until the correct datatype becomes available.--Jasper Deng (talk) 19:38, 7 September 2013 (UTC)

given name (P735): (delete | history | links | entity usage | logs | discussion) Unappropriate datatype.

 Delete The property was added without reaching a consensus. The "status report" on the talk page is miscalculated, there are only 5 voices supporting the property as proposed (and created).

The item datatype is not distinct enough to describe the form of the name to be matched with the described person. A name item can refer to the name in various forms (e.g. en:Katherine (given name)#English). Moreover, the labels in various languages choose one of the possible forms of the name which may or may not be suitable for the described person. There's a big variety in the question which names should be translated and which should be left in the original language (after transcription into the local alphabet eventually); different approaches can be found not only between different languages, but also in one language, depending on time period, life story, profession etc. The example given in the discussion works well with English, but the labels of the item Georg (Q1985538) would tell us that Washington's given name was Juraj (in Slovak), Георгий (in Russian) or ホルヘ (in Japanese. The labels of George Washington (Q23) on the other hand use the form George (in Slovak), Джордж (in Russian) and ジョージ (in Japanese). The other way round, Božena Němcová would be awarded with the given name Bożena in English and the actual Czech president gets a nice 19th century styled digraphed form Milosz.

The property is essentially correct, but it doesn't tell anything more than "One of the given names of George Washington (Q23) is some form of the name Georg (Q1985538)". That's virtually useless for Wikipedia. Theoretically we could use it to make a wikilink to the article about the name, but still we don't know what should be written in the description of the link.

Therefore I suggest deleting the property and creating it as MultilingualText datatype (when available).--Shlomo (talk) 16:39, 5 August 2013 (UTC)

 Delete It was deleted once before as Property:P152 and Property:P153 (see and search in archive). JAn Dudík (talk) 21:39, 5 August 2013 (UTC)
 Keep Same as family name (P734). — Ivan A. Krestinin (talk) 21:53, 5 August 2013 (UTC)
 Delete Same as family name (P734). --Stryn (talk) 21:18, 6 August 2013 (UTC)
 Keep Item is the correct datatype. Use this as a qualifier for P513 (P513) or for a 'name' property with string/monolingual datatype. Filceolaire (talk) 10:28, 17 August 2013 (UTC)
 Keep --Nightwish62 (talk) 10:23, 20 August 2013 (UTC)
 Keep recreating or changing to MultilingualText datatype doesn't seem like a good reason to delete this now. If it is to be MultilingualText, surely it should be kept until that happens? Danrok (talk) 14:26, 2 September 2013 (UTC)
 Keep until the same with "multilingual text" is created, then  Delete. Littledogboy (talk) 15:33, 3 September 2013 (UTC)
{[keep}} Shlomo, you may be amused but in Russian given name of George Washington (Q23) is really "Джордж" :) --Infovarius (talk) 13:57, 4 September 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

family name (P734)

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

 Not deleted - consensus to delete not reached, at least not until the right data type becomes available.--Jasper Deng (talk) 19:36, 7 September 2013 (UTC)

family name (P734): (delete | history | links | entity usage | logs | discussion) Unappropriate datatype.

 Delete The property was created after a tight vote (in fact 10:9, not 13:4 as stated on the talk page...) and with a lot of important remarks left unanswered.

Like the #Property:P735, the item datatype doesn't tell us clear enough, which form of the name the person uses/used. AFAIK all the Slavonic languages (and probably some other languages too) differentiate between the male and female form of the family name, some of them have even several female forms. The articles on Wikipedia (and consequently the items on Wikidata) are generally (and IMHO correctly) assigned to the name covering all it's variants - sometimes (but not always) differentiating between various spellings, like Švarc (Q10502447), Schwarz (Q20267) and Schwartz (Q2253338) and exceptionally differentiating between gender variants, like Novak (Q729388) and Nováková (Q3345550).

The property is essentially correct, but it doesn't tell anything more than "One of the family names of Božena Němcová (Q157970) is some form of the name Němec (Q1977134)". That's virtually useless for Wikipedia. Theoretically we could use it to make a wikilink to the article about the name, but still we don't know what should be written in the description of the link.

Therefore I suggest deleting the property and creating it as MultilingualText datatype (when available).--Shlomo (talk) 17:19, 5 August 2013 (UTC)

  •  Keep Good property, allows to link article about surname and surname owners. Gender is not problem at least in Russian. This is only forms of one surname. For example Kuznetsov (Q4245091) is about both male (Кузнецов) and female (Кузнецова) forms. — Ivan A. Krestinin (talk) 18:10, 5 August 2013 (UTC)
    That's what I'm saying, the item is about both Кузнецов and Кузнецова, but is only labeled as Кузнецов. If you use this property in an article about Svetlana Kuznetsova (Q192064), you will get the male form of the name as a result... (together with the correct link, that's right).--Shlomo (talk) 18:24, 5 August 2013 (UTC)
There. Fixed. I renamed the items as 'Němec/Němcová' and 'Kuznetsov / Kuznetsova' so you can use P734 to link to this and it is right whether the subject is a man or a woman. Filceolaire (talk) 19:51, 5 August 2013 (UTC)
You should add also 'Nemec', 'Nemcova' and 'Nimets' (as for now). But could a statement like this be used in a Wikipedia infobox (or elsewhere)?--Shlomo (talk) 20:40, 5 August 2013 (UTC)
Currently ru:Шаблон:Имя have link to report "all persons with this name". Current implementation is not good because it finds the substring in page names only. Implementation based on given name (P735) will be more reliable. — Ivan A. Krestinin (talk) 21:52, 5 August 2013 (UTC)
It surely will. But the MultilingualText datatype will enable you to control the search better. The Item gives you a set of all people who use any form of the name. E.g. if you'll be looking for Peter (Q2793400), you will get everybody called "Петр", but also everybody called Peter, Petr, Pierre, Pedro, Petur, Petelo, Pit, Pêr etc. Is this what you want? If there will be a property with the exact form of the name, you can design the query to find just the form(s) of the name you want.--Shlomo (talk) 23:38, 5 August 2013 (UTC)
Note that Multilingual datatype won't help here since it only allows one English and one Russian value. Filceolaire (talk) 19:51, 5 August 2013 (UTC)
It will help. One value per language and person is enough. Božena Němcová (Q157970) will get (en:Němcová,ru:Немцова,...) while Svetlana Kuznetsova (Q192064) will get (en:Kuznetsova,ru:Кузнецова,...)--Shlomo (talk) 20:40, 5 August 2013 (UTC)
 Delete It was deleted once before as Property:P152 and Property:P153 (see and search in archive). JAn Dudík (talk) 21:41, 5 August 2013 (UTC)
  • Why would an item covering both Němec and Němcová be used for a person who has one of those names? Shouldn't a more specific item be used? Also, being useless for Wikipedia doesn't mean we should delete the property. Wikipedia is not the sole use-case for the free knowledge base. --Yair rand (talk) 21:57, 5 August 2013 (UTC)
    The same reason, why would an item covering both Obama and Obamová be used for a person who has on of those names. These are not two names, just two forms of the same name. In some languages. While other languages may use only one form. Or three forms.
    Your other point sounds stronger. We don't have to delete a property which is essentially correct just because we don't have any use for it in the Wikipedia. We can have one family name property as an item datatype and another one as a multilingual text. Actually, we can use them together, one as a qualifier of the other.
    I'm just afraid of sourcing the item-typed name-properties. We surely can find a source that assignes George Washington (Q23) to the given name "George". But is it enough to assign him to the item Q1985538 which is defined by 40 forms of the name, if we cannot bring a source for all of them? And especially, if some of them clearly don't match with the person (but can't be separeted from the name-item)? The problem is more obvious for the given names, but is essentially the same for the family names.--Shlomo (talk) 23:38, 5 August 2013 (UTC)

Will we have Jiří (Q168563) shrub (Q42295) as american president? :-) Yes, better property for surname should be used, but this one is good ilustration - try to change language... JAn Dudík (talk) 05:51, 6 August 2013 (UTC)

No, this is a bad example. You can stultify any property (good or bad) by choosing unappropriate value for it. If you use the "correct" ones, you'll get Georg (Q1985538) Bush (Q224168) - which is bad enough, if you change language e.g. to Slovak or Finnish...--Shlomo (talk) 06:27, 6 August 2013 (UTC)
Those were incorrect sitelinks. I've moved the Finnish "Yrjö" to Yrjö (Q14508216) and Slovak "Juraj (prvé meno)" to Juraj (Q3513270) where they belong. --Yair rand (talk) 20:23, 6 August 2013 (UTC)
Well done. Please change (or remove) the corresponding labels in cases like this, if you can. There's a lot of mismatched names like these and I'm afraid not all of them can be corrected. I'm happy though that a discussion over these properties brings some improvement in this field ;)--Shlomo (talk) 21:40, 6 August 2013 (UTC)
 Delete. I don't see any good reason to keep this. --Stryn (talk) 21:16, 6 August 2013 (UTC)
 Comment Uh, I can't remember. What was the reason for Wikidata again? Ahhh, query data. If we aren't able to query a person which surname is 'XYZ', then we should close Wikidata immediately. --Nightwish62 (talk) 10:29, 20 August 2013 (UTC)
 Comment We can use search engine to find names. What next? Maybe "middle name" property... --Stryn (talk) 04:17, 27 August 2013 (UTC)
I don't have any clue what you're talking about "using search engine"? Internal or external search engine? However, here something you should read: W:Database_normalization. --Nightwish62 (talk) 10:50, 28 August 2013 (UTC)
 Keep Use this as a qualifier for P513 (P513) or for a 'name' property with string/monolingual datatype. Filceolaire (talk) 10:30, 17 August 2013 (UTC)
 Keep --Nightwish62 (talk) 10:29, 20 August 2013 (UTC)
 Comment: Can we turn this into vote on changing the property type (for both) to multilingual text, instead of deletion? Littledogboy (talk) 11:29, 27 August 2013 (UTC)
I'd like to agree, I'm just not sure if this is technically possible.--Shlomo (talk) 16:40, 29 August 2013 (UTC)
 Keep pending the possibility of data type change. Danrok (talk) 14:29, 2 September 2013 (UTC)
 Keep until the same with "multilingual text" is created, then  Delete. Littledogboy (talk) 15:33, 3 September 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P871

P871 (P871): (delete | history | links | entity usage | logs) Created by mistake, redundant to P870--GZWDer (talk) 10:21, 11 September 2013 (UTC).

Property:P890

P890 (P890): (delete | history | links | entity usage | logs) Same as above.--GZWDer (talk) 10:53, 11 September 2013 (UTC).

Property:P869

P869 (P869): (delete | history | links | entity usage | logs) See P:P900 and its talk page..--GZWDer (talk) 09:31, 12 September 2013 (UTC)

✓ speedy-deleted --Ricordisamoa 12:34, 12 September 2013 (UTC)
Would create it with string datatype and delete P:P900 as well? --  Docu  at 18:41, 12 September 2013 (UTC)

Property:P900

P900 (P900): (delete | history | links | entity usage | logs) See comments above..--GZWDer (talk) 10:08, 13 September 2013 (UTC)

✓ Done John F. Lewis (talk) 18:45, 13 September 2013 (UTC)

P283 (P283), P284 (P284), P285 (P285)

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 for deletion of all three. Will be deleted once deprecated. John F. Lewis (talk) 18:47, 13 September 2013 (UTC)

Subsumed by P133 (P133). Relationships between language families can be expressed with subclass of (P279). I floated this on Wikidata talk:Languages task force a few days ago, with some more details about why precisely they're not useful and some more thoughts about language taxonomy, but no-one had anything to say.  Delete KleptomaniacViolet (talk) 15:24, 3 September 2013 (UTC)

I'm thinking of an RfC for language taxonomy representation. There are a fair number of issues to sort out around how exactly to relate languages to families and families to other families (assuming we make the distinction). KleptomaniacViolet (talk) 16:51, 3 September 2013 (UTC)
An RfC wouldn't get any attention, so don't loose your time with it. --Nightwish62 (talk) 17:24, 3 September 2013 (UTC)
If you are not interested in linguistic, that doesn't mean that others also don't. I believe that the RfC would be useful. Infovarius (talk) 08:31, 12 September 2013 (UTC)
 Delete and use subclass of. --Nightwish62 (talk) 17:24, 3 September 2013 (UTC)
 Delete Filceolaire (talk) 14:41, 6 September 2013 (UTC)
 Delete per nom. --Ricordisamoa 21:41, 6 September 2013 (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.

Kept for now, premature nomination. Discussion can be reopened when Phase 1 for Commons has started and we see how it works. -- Lavallen (talk) 13:55, 17 September 2013 (UTC)

Commons category (P373): (delete | history | links | entity usage | logs | discussion) Lydia Pintscher says Commons is coming. if we can link People's Republic of China (Q148) to commons:中国 and Category:China (Q1411230) to commons:Category:China, P373 will be redundant to category's main topic (P301).--GZWDer (talk) 09:55, 9 September 2013 (UTC).

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

P387 (P387)

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 or strong discussions presented in either argument which cancel out the opposing side. John F. Lewis (talk) 13:28, 21 September 2013 (UTC)

P387 (P387): (delete | history | links | entity usage | logs | discussion) There are two reasons:

  1. These values may contain excessive or improper use of non-free material. no fair use is allowed.
  2. Wrong datatype, needs to be Monolingual texts, which is not available..

--GZWDer (talk) 10:34, 6 June 2013 (UTC)

I'm not even sure how this is intended to be used, where is the proposal discussion? —★PοωερZtalk 16:58, 6 June 2013 (UTC)
I think this was created without long discussion because of the corresponding parameter in a wikipedia infobox. Snipre (talk) 01:32, 7 June 2013 (UTC)
 Delete per nom. --Ricordisamoa 22:25, 6 June 2013 (UTC)
  • datatype: I did not know about "monolingual text" when I created this property, and I still do not know exactly how it will be different from string, does anyone know about that ? I suppose we have the same isse with P357 (P357).
  • discussion: I think I had proposed it, but there were no comments before I created it.
  • use: it has at least two:
  1. make sure that the claim is really made in the purported source. I have seen countless examples in Wikipedia where it is not the case.
  2. qualify the claim, when there are important things that cannot be adequately be said in pure database language. For instance, it is hard to say who is depicted in Venus de Milo (Q151952), and I think the quote provided in Mérimée ID (P380) helps with that.
  • Copyright: that is the main problem imo. I think that short quotes are legally acceptable in just about every circumstance, but I suppose that does not technically remove the copyright. Note that the situation seems to be the same in Wikipedias, as the quoted texts are not CC-BY-SA either.--Zolo (talk) 09:01, 7 June 2013 (UTC)
  • Citing fair use in defense of this property seems invalid on its face. As the site's footer notes, Wikidata's "structured data from the main and property namespace is available under the Creative Commons CC0 License". In other words, by putting quotes into a Wikidata claim (a subject-predicate-object, a unit of structured data), we would implicitly be asserting that those quotes are in the public domain. Subjects to which fair use applies are copyrightable; they are not in the public domain. A proper defense of this property would argue that quotes are not copyrightable. The article Copyright Protection for Short Phrases from the Stanford Copyright and Fair Use website seems like it could provide some guidance on this. Emw (talk) 01:22, 13 June 2013 (UTC)
Any comment on this? Copyright issues are this property's main problem, and it seems like that's not being addressed. Emw (talk) 14:36, 7 September 2013 (UTC)
I have quoted this document many many times on Wikipedia, I have even uploaded it to Commons, since it is from early 1900. Do you have any problems with that I will copy small parts from this document here on Wikidata into this property? -- Lavallentalk(block) 16:38, 7 September 2013 (UTC)
How about datatype? Should it be Monolingual texts?--GZWDer (talk) 16:01, 11 June 2013 (UTC)
I think so, and so for P357 (P357) I would say, and really I do not know what we should do about that. I would guess go for an approximate datatype until a better one is available. We can do without P387 for a while, but deleting P387 would be really problematic, so I suppose we will need to clean things up once monolingual texts are available in any case. --Zolo (talk) 16:33, 11 June 2013 (UTC)
 Keep only for use in sources. Filceolaire (talk) 08:58, 13 June 2013 (UTC)
 Delete but weak. if we provide the data of the source we don't need the quote, each person can find the information in the source. Quote is useful only when the statement in the source is not clear or when you want to discuss the qoute itself in a text. Snipre (talk) 13:12, 27 August 2013 (UTC)
Also image (P18) can contain non-free material. And sources can be old enough or free in some cases.  Keep until better datatype is available. -- Lavallentalk(block) 13:19, 27 August 2013 (UTC)
No, image (P18) can't contain non-free material, because it only allows images on Commons, and Commons doesn't allow non-free material. Sven Manguard Wha? 05:48, 6 September 2013 (UTC)
If it's free or not depends on where you live. Copyright-laws do not look the same everywhere. There are thousands of pictures on Commons I wouldn't use if I would publish a book, or even use on Wikipedia. -- Lavallentalk(block) 06:18, 6 September 2013 (UTC)
 Keep --Nightwish62 (talk) 11:01, 6 September 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P719 (P719)

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 for deleting P719 (notable incident). I've changed the English language label for P793 to better reflect the property's intended purpose, with the old name as an alias and P719 as an alias. Sven Manguard Wha? 03:21, 21 September 2013 (UTC)

P719 (P719): (delete | history | links | entity usage | logs) P719 (P719) is superceded by significant event (P793).

I don't think we have to delete all incident/event related properties now that we have significant event (P793) but I think P719 (P719) can go. Filceolaire (talk) 14:38, 6 September 2013 (UTC)
 Delete. No clear difference between the two. --Zolo (talk) 10:08, 9 September 2013 (UTC)
 Delete per nom. --79.40.79.94 07:57, 19 September 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P302 (P302)

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'm not sure of the wisdom of this path of stuffing more and more information into 'instance of' rather than using more specific properties, but consensus is clear for deletion here. Sven Manguard Wha? 03:44, 21 September 2013 (UTC)

P302 (P302): (delete | history | links | entity usage | logs) Given its currently low use, and its duplication of the subclass of (P279) and instance of (P31) chain, I am proposing this property for deletion. I would replace every one of its uses today but were it for the fact that people get really unhappy when talking about a type property. This property also suffers the same problems as the notion of a main type, which is another reason to delete it. --Izno (talk) 18:53, 14 September 2013 (UTC).

 Delete --Nightwish62 (talk) 21:21, 18 September 2013 (UTC)
 Delete --79.40.79.94 07:59, 19 September 2013 (UTC)
 Delete --Filceolaire (talk) 17:49, 19 September 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

image (P18)

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.

Kept. Legoktm (talk) 03:59, 21 September 2013 (UTC)

image (P18): (delete | history | links | entity usage | logs | discussion) Wikidata is all about specific data for a certain item. But there is no specific image for any topic, rather there is a potentially unlimited number of ways you can illustrate an item. On first impulse you might say: why, it's easy to define the portrait of a person. But the Commons category of Albert Einstein shows a wide range of images from the different stages of his life. Even if you would try to limit the selection to the "latest" image or the image at the "time of his greatest success" there would still be a high number of candidates and it would be an arbitrary choice. Or if this property would require the most "famous" picture (a questionable distinction) with Einstein it would rather be the famous "tongue" image. But this is no appropriate photography for an encyclopedic biography, not as the image "defining" the topic anyway.

And although many articles deal with people's biographies, most articles have topics that are even more difficult to illustrate. What is a city? The sign at the city limits? A satellite image? "The one" most "famous" sight? Even worse are abstract concepts like "happiness". Take the image of choice for Q8: Is this an image of "happiness"? No, it's the picture of a woman kissing a baby. Of course many people might regard this as a typical moment of happiness, many others won't. It is a question of individual experiences, of different cultures, and even of different languages. The German article linked there is "Glück", but this word also translates as "luck" or "chance". So a German might consider a four-leaf clover, a horseshoe, dice or a Roulette wheel a good illustration for Q8. Neither would be a good illustration for "happiness" though. But people already start to link the Wikidata picture P18 in the articles without having control over the content. Wikidata is a central database that the different Wikipedias can link to, at least to the reliable data and properties. But images are not reliable and it would be difficult to rule out images while allowing all other data. And what good would the image be, if you cannot link it?

So my reasoning is: there is no way to find or define "the one" image that illustrates a Wikidata item. The choice will always be an arbitrary one and not everybody and not every Wikipedia will agree with the individual choices. This is not a typical property for Wikidata and there can be no general rules to define the one image that should be the Wikidata illustration. The only appropriate way to deal with this problem is to give the link to the Commons category and leave the user the choice of the "right" image for the article in his or her Wikipedia. Accordingly the property P18 should be deleted. -- HvW (talk) 09:53, 16 September 2013 (UTC)

 Keep I agree that the prefered image is the article-editors choise, but in some cases is image (P18) a good property, for example in art-related items. I have myself used this property in items related to coat of arms (P237), where the alternatives in the categories often are few. -- Lavallen (talk) 11:07, 16 September 2013 (UTC)
Even if you could define "the one" coat of arms image for the whole WP (CoA, Flags etc. can change over time, files can have different colours, sizes, resolutions, and so on), a better solution would be a specific property for all WP standard files. You can't ignore all the other problems for almost all of the other items just because you think it works in some singular cases. -- HvW (talk) 12:00, 16 September 2013 (UTC)
It's wrong to add sex or gender (P21) in random items too, but I do not propose it to be deleted! If the CoA change over time, we can add qualifiers for it or create new items, since change of CoA often is a consquence of some other changes, like changes from Town to City or to Municipality or anything else... Such things happend a lot in the 1970's where I live.
I fully agree that the use of P18 in many items have to be reviewed, and I will not recomend the use of this property in random templates on Wikipedia. -- Lavallen (talk) 12:54, 16 September 2013 (UTC)
You don't seem to understand the problem. It's not the silly "it can be used wrong so delete it" argument. You can decide whether male / female is right or applicable. You can not decide, what image is the right one. As long as there is a general property Image for all items you can choose any image you like that makes any sense and nobody can tell why it shouldn't be this image or why there should be no image at all. You link your CoA image, somebody else replaces it with a file twice the size, the next one found an image from an old book with darker colours. Wikidata properties have a limited range of values, images have unlimited variations, even if you would think there is only "the one" coat of arms. You can define images of a certain resolution, size and file format as standard images e. g. for national flags. Then you can create a property for flag or state articles to include these images. But it is obvious that there can be no standard for almost the whole rest of the world. That is why this "general" property does make no sense. -- HvW (talk) 13:54, 16 September 2013 (UTC)
We can decide that this and that "range of items" is not in "the range" for any property, just like we can decide if mythical items and/or fictional items and/or items about groups of humans are supposed to use P21 or not. In the end is it the template-designers in the client who choose to use a property or not. From my point of view, P18 is maybe the only media-file-property we need. -- Lavallen (talk) 14:29, 16 September 2013 (UTC)
No, you can't decide anything about a "range". No more than about "the one" image. The different examples should have made this clear. In a way you got the point. If anybody uses this property it's their own fault. -- HvW (talk) 21:23, 18 September 2013 (UTC)
"If anybody uses this property it's their own fault." - Well yes, that is true about all properties here, and about every parameter in every template... -- Lavallen (talk) 09:47, 19 September 2013 (UTC)
 Keep Part of the reason we have this property is so that infoboxes can be populated with an image via template. In smaller projects where there aren't enough people for it to be feasible for someone to go through each Commons category to find the 'best' image for each subject, they can use the one in the image field. That's a powerful function, and one that people increasingly seem to forget about on this page. Sven Manguard Wha? 01:05, 17 September 2013 (UTC)
A sledge hammer is a powerful tool, but not of much use if you want to pin a postcard on the wall. You can do so many things with this unspecific property and people do them all at once. And that does not make it powerful but useless for the specific uses you want to put it to. If you want infobox images, create a property "infobox-image" and define exactly what you want there. If you want flags for flag or country articles, create a property "flag-image". But "image" is everything and nothing at the same time. -- HvW (talk) 21:23, 18 September 2013 (UTC)
 Comment Currently we have 1732 items with multiple P18 values: [1]. Do somebody know how to choose one of the images in infobox code? For example for Q336191, Q461793. — Ivan A. Krestinin (talk) 04:41, 18 September 2013 (UTC)
You can look into how enbarten is used in sv:Modul;Wikidata. If the module has the parameter enbarten=0, then the first file is collected. enbarten=1, gives the second etc... Many other things in the code in this page has not been updated and I give no guarantees that it works today. -- Lavallen (talk) 05:48, 18 September 2013 (UTC)
Question is not about code. It is about algorithm logic: what image the infobox must use? The first? The last? Random? The best (but how to identify the best image)? — Ivan A. Krestinin (talk) 06:41, 18 September 2013 (UTC)
Agree, we have to solve that. I am currently (and maybe for several years from now) working with Swedish Municipalities. The most frequent illustration on svwp is the office-building of the municipal administration. I guess it would be nice if we could create relations to an item about the building and in that item use P18, instead of putting them directly into the municipality-item, which tells very little today about it's relation to the item. -- Lavallen (talk) 07:25, 18 September 2013 (UTC)
 Keep. While there may be disagreement as to which is the best image that doesn't mean we can't have any.
Where multiple images are listed we will be able to specify one of these as the preferred image, once the developers have the ranking facility available. Filceolaire (talk) 17:15, 19 September 2013 (UTC)
 Keep --Nightwish62 (talk) 20:59, 20 September 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

highest point (P610)

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.

Kept. Lavallen (talk) 17:32, 15 October 2013 (UTC)

highest point (P610): (delete | history | links | entity usage | logs | discussion) The datatype should really be coordinate, not item. This change would allow us to enter in high point data without creating items for non-notable hills in the middle of nowhere. --Jakob (Scream about the things I've broken) 15:52, 7 October 2013 (UTC).

Then you have to add statement is subject of (P805) to identify Mount Everest (Q513) in Earth (Q2) and then add the coordinates of Q513 in two items! Would it not be better to use "somevalue" in P610 and coordinate location (P625) as qualifer when the place lack wp-notability? -- Lavallen (talk) 17:05, 7 October 2013 (UTC)
Thanks for the tip. I didn't think if that. I withdraw this nomination. --Jakob (Scream about the things I've broken) 12:02, 8 October 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P955

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

Deleted. Lavallen (talk) 17:32, 15 October 2013 (UTC)

P955 (P955): (delete | history | links | entity usage | logs) Sorry, wrong data type. My fault. --Kolja21 (talk) 16:21, 15 October 2013 (UTC).

✓ Done --ValterVB (talk) 16:57, 15 October 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P983

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

Deleted. The Anonymouse (talk) 15:50, 29 October 2013 (UTC)

P983 (P983): (delete | history | links | entity usage | logs) Created by mistake. Should be string. Will create a correct P985 (P985)..--GZWDer (talk) 11:04, 23 October 2013 (UTC)

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

Property:P986

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

Deleted. The Anonymouse (talk) 15:50, 29 October 2013 (UTC)

P986 (P986): (delete | history | links | entity usage | logs) Wrong property created when trying creating P985. P988 is created.--GZWDer (talk) 11:06, 23 October 2013 (UTC).

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

P540 (P540) or P766 (P766)

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 appears to be clearest for deleting Venue and only Venue. Venue will be deleted as soon as all instances of venue are replaced with location. Sven Manguard Wha? 08:27, 7 September 2013 (UTC)

One of these two properties should be deleted:

I initially proposed the deletion of P766 (P766) for these reasons:

  1. This property was recently created by its proposer without any discussion at all.
  2. This property is redundant to located in the administrative territorial entity (P131) P540 (P540).
  3. P131 has a constraint that says it applies only to geographical features, but it could be changed to include events.

However, I now think it would be better to keep P766 (P766) and delete P540 (P540). As the property creator explained, P766 (P766) covers more cases like events that are not held in venues and events that just happen, like natural disasters. So my final vote is:  Keep P766 (P766),  Delete P540 (P540). Apologies for the confusion. Mushroom (talk) 15:34, 7 August 2013 (UTC)

  •  Keep, these are different relation types. Current ru-label "находится в административной единице" does not allow to use this property for events. — Ivan A. Krestinin (talk) 20:20, 6 August 2013 (UTC)
Actually the current labels for both of these only allow them to be used for events, except in Russian where "venue" doesn't have a label. Filceolaire (talk) 12:34, 2 September 2013 (UTC)
  •  Keep, it isn't redundant to located in the administrative territorial entity (P131) as this property is limited to only administrative units. How will you make e.g. this statement here West German Embassy siege (Q531412)? The German Embassy isn't an administrative unit, so it can't be used. located in/on physical feature (P706)? Doesn't work also. And even if you find (or create) a property for locating non-administrative unit, this would mean we have events spread over two different properties. Not easy or logical when you're searching all events for a specific location, because you've always to considering both properties. --Nightwish62 (talk) 22:57, 6 August 2013 (UTC)
  •  Comment BTW: I'm not an English native speaker, but I believe even in English the term "is in administrative unit" doesn't fit for events. --Nightwish62 (talk) 06:28, 7 August 2013 (UTC)
  •  Comment Thanks for the explanation, I understand your reasoning and have amended my deletion request. But what about P540 (P540)? We still have two properties for what is basically the same concept, i.e. the place where the event was held. In English it doesn't sound quite right to say that the West German Embassy siege (Q531412) was held at a venue, but the Italian label for P540 (P540) is "luogo" (location), the French one is "lieu" (location), the Catalan is "lloc" (location), the Dutch is "locatie" (again, location), so there is much ambiguity. I think we should either delete P766 (P766) and give a broader sense to P540 (P540), or just delete P540 (P540). What do you think? Mushroom (talk) 08:17, 7 August 2013 (UTC)
    I think administrative units instances corresponds to geographical locations, but other kind of geographical location (like a mountain) tends to be more geographically stable other time (a mountain does move but in geological times :)). For administrative units, it's not the same : some can disappear, appear, move, ... so the statement will make sense if we also have the date. But I agree, when we give the place of an event, we should give a geographical location (a subclass of geographical location instance). The problem is wether or not we consider if we have an administrative unit and a date, we also have a geographical location. If we consider that as a fact, then we can have one generic property. TomT0m (talk) 09:39, 7 August 2013 (UTC)
     Comment Funny. I never saw the venue property. Otherwise I wouldn't created P766. It's a shame the venue property didn't get any "also know aliases". I think venue could work for events. But I can't tell if it's suitable for all kind of events and what's about other languages. It seems 'venue' is used for scheduled events with audience (event = Veranstalltung), not for events which just happens (event also = Ereignis), like a disaster. But it really seems like venue and location/place are very similar or redundant. Even so, we have to decide which to delete and which to remain. --Nightwish62 (talk) 11:07, 7 August 2013 (UTC)
    Actually you did good, while I made the deletion proposal too hastily and on bad assumptions. Even if you didn't know about P540 (P540), you created a much better property because it covers all events that don't have a venue and also those that just happen. So my new proposal is to keep P766 (P766) and delete P540 (P540). If you agree, please update your vote accordingly. Mushroom (talk) 15:34, 7 August 2013 (UTC)
    Cool we were able to discuss this out. Yes, now I'm voting for  Delete for P540 (P540). --Nightwish62 (talk) 16:49, 7 August 2013 (UTC)
  • One question in general: Will in such cases a bot change all existing 'venue' to 'location'? Is this possible and/or already done before? I think we should have such a bot which can be used to change the property to another property. --Nightwish62 (talk) 16:56, 7 August 2013 (UTC)
  • Should the labels (en, de, fr, ?) for the property P766 (P766) not be more specific and indicate that is only suitable for events? As for example the property place of publication (P291) clearly indicates by its label, that it is only suitable for creative works. For geographical objects one could then use located in/on physical feature (P706) or located in the administrative territorial entity (P131) (the first one explicitely mention also events in its description; how to deal with that?).--Zuphilip (talk) 11:20, 8 August 2013 (UTC)
There is a discussion on the Property_talk:P766 page for "location" about widening this property so it can be used for objects as well as events. Please don't change the labels until this is resolved. Filceolaire (talk) 12:50, 2 September 2013 (UTC)
For events and objects in states, cities, towns I think we should use "is in the administrative unit". For events and objects on rivers, mountains, lakeshore etc. we should use "located on geographical feature". For events and objects in stadiums, museums, galleries, streets, villages (where these have items) we should use "location". "Venue" could be used for stadiums and theatres but not for museums and streets so it should (in my opinion) be deleted and "location" used instead. Filceolaire (talk) 12:45, 2 September 2013 (UTC)
 Delete Venue. Keep 'location' but widen it's use so it can be used for things like the museum an art work is in. heading over to P766 (P766) to propose this now. Filceolaire (talk) 11:37, 20 August 2013 (UTC)
  •  Keep We need both properties then the definitions should be modified: we need a property for event and one property for physical place. Some events take place at different places so we need to use sometimes twice the same property and as we have now already two properties we can use both of them. Discussion there Snipre (talk) 12:58, 1 September 2013 (UTC)
What do you mean by a "property for event" and a "property for physical place"? Both of these properties have "event" as their subject/domain (the page they are used on) and a physical place as their object/range (the page they point to).
If an event takes place in two places then use the same property twice. Please don't use two different properties for the same concept. Filceolaire (talk) 12:23, 2 September 2013 (UTC)
 Delete (merge) P540 (P540) because a P540 (P540) is a P766 (P766). The word venue is not limited to specific types of places, in the English language. Any place can be a venue. Danrok (talk) 14:52, 2 September 2013 (UTC)
 Delete P540 (P540) French labels currently state just the same: location of an event. P766 (P766) label could be made more general and its constraint widened to cover both events & places - LaddΩ chat ;) 16:54, 2 September 2013 (UTC)
 Delete There are some interesting language issues brought up above, but in the two languages that I understand it seems that P540 (P540) is a location, and is thus not needed. Ajraddatz (Talk) 17:05, 2 September 2013 (UTC)
 Comment I have started a more general RFC for 'Place' related properties. Part of that is looking at whether we might delete both of these. Filceolaire (talk) 17:34, 2 September 2013 (UTC)
Unnecessary RfC which wouldn't get any attention like all RfCs I remember. --Nightwish62 (talk) 17:32, 3 September 2013 (UTC)
Please, would any admin FINALLY delete 'venue'? Isn't the voting not clear enough? How many discussions and RfC should we start before someone finally act? --Nightwish62 (talk) 17:32, 3 September 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

station code (P296)

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

Not deleted, because there was no consensus reached.--Jasper Deng (talk) 08:25, 1 November 2013 (UTC)

station code (P296): (delete | history | links | entity usage | logs | discussion) This property is too generic, and contains mixed contents. We may want to create more specific properties (eg. USSR railway station code) instead and migrate existing contents in this property. See Property talk:P296. Liangent (talk) 17:47, 20 September 2013 (UTC)

Station codes of en:Takamatsu Station (Kagawa)
  •  Keep for generic station numbers with qualifiers. I'm thinking of cases like stations in China, Japan, Korea, and Singapore, with very short station numbers unique only within a particular line or company, but nevertheless is used very commonly on every signs and announcements. Example: en:Namba Station is NK01 for Nankai Railway, and M20, S16, Y15 for the three subway lines. (But if you go to Tokyo, M20 resolves to en:Ochanomizu Station.) In this case, the best option is clearly to use a generic property like this one, with a qualifier to indicate the line. --朝彦/Asahiko (talk) 04:21, 23 October 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P185

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.

Kept. Sven Manguard Wha? 20:29, 29 October 2013 (UTC)

doctoral student (P185): (delete | history | links | entity usage | logs | discussion) Merge to student (P802).--GZWDer (talk) 11:29, 17 October 2013 (UTC)

 Oppose Everyone can call himself "student of" if he has visited a seminar. A doctoral student is a much higher level and it's a fact. "Student of" you can debate on. It's the same distinction as in en:Template:Infobox scientist: "doctoral_students" and "notable_students". --Kolja21 (talk) 18:28, 17 October 2013 (UTC)
 Oppose "студент" and "аспирант" are different roles in Russian learning system. Relations "студент-преподаватель" and "аспирант-научный руководитель" are very different too. — Ivan A. Krestinin (talk) 20:17, 17 October 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P177

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.

Kept. Sven Manguard Wha? 20:37, 29 October 2013 (UTC)

crosses (P177): (delete | history | links | entity usage | logs | discussion) Merge to located in/on physical feature (P706).--GZWDer (talk) 15:03, 17 October 2013 (UTC)

  •  Keep, meaning is not really the same (crossing the Thames is not really the same as being located in the Thames). At the very least, this property is much more precise and would be useful in several infoboxes.(and probably various sorts of queries as well). --Zolo (talk) 20:49, 17 October 2013 (UTC)
  • Oppose: There is probably a roads-related property this could be merged with. "Located on terrain feature" is not one of those. --Izno (talk) 17:06, 19 October 2013 (UTC)
    The name of a merged property might be something like "intersection". --Izno (talk) 17:10, 19 October 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Some Statistics Sweden (Q1472511)-codes

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

Speedy deleted. Sven Manguard Wha? 21:09, 29 October 2013 (UTC)

Property:P979

Duplicate of Church of Sweden Pastoratskod (P779). Michiel1972 (talk) 10:08, 29 October 2013 (UTC)

Property:P978

Duplicate of Church of Sweden parish code (P778). Michiel1972 (talk) 10:06, 29 October 2013 (UTC)

Property:P977

Duplicate of Swedish civil parish code/ATA code (P777). Michiel1972 (talk) 10:06, 29 October 2013 (UTC)

Property:P976

Duplicate of Swedish minor urban area code (P776). Michiel1972 (talk) 10:06, 29 October 2013 (UTC)

Property:P975

Duplicate of Swedish urban area code (P775). Michiel1972 (talk) 10:06, 29 October 2013 (UTC)

Looks like a correct observation. -- Lavallen (talk) 10:39, 29 October 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P164

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. This action will be performed shortly. No one has objected to this PFD for over two weeks. --Jakob (Scream about the things I've broken) 21:18, 7 November 2013 (UTC)

P164 (P164): (delete | history | links | entity usage | logs) Use member of (P463) or part of (P361) instead.--GZWDer (talk) 05:16, 18 October 2013 (UTC)

 Delete In contrast to airline alliance, railway alliance is in wikipedia nowhere used. --Pasleim (talk) 15:22, 29 October 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P734 (surname)

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 for keeping this, at least for the time being. Sven Manguard Wha? 04:44, 15 November 2013 (UTC)

family name (P734): (delete | history | links | entity usage | logs | discussion) Same as above. Merge this and those two below to a new name property with item datatype. There will be two name property -- one with item datatype and one with monolingual datatype. (or can even merged to one monolingual datatype property)--GZWDer (talk) 10:08, 8 November 2013 (UTC)

And my vote here is also  Keep until relevant datatypes are available. -- Lavallen (talk) 11:23, 8 November 2013 (UTC)
 Keep This has datatype 'item' and links to a page for the surname. This is a very different property and cannot be replaced by 'name'. Filceolaire (talk) 16:27, 8 November 2013 (UTC)
 Keep, link between person and article about his surname is not good idea. — Ivan A. Krestinin (talk) 19:44, 8 November 2013 (UTC)
 Keep The property name is comprehensive. לערי ריינהארט (talk) 19:52, 14 November 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P735 (given name)

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 for keeping this, at least for the time being. Sven Manguard Wha? 04:44, 15 November 2013 (UTC)

given name (P735): (delete | history | links | entity usage | logs | discussion) Same as above.--GZWDer (talk) 10:08, 8 November 2013 (UTC)

And my vote here is also  Keep until relevant datatypes are available. -- Lavallen (talk) 11:24, 8 November 2013 (UTC)
 Keep. See 'surname' above. Filceolaire (talk) 16:29, 8 November 2013 (UTC)
 Keep per above. — Ivan A. Krestinin (talk) 19:45, 8 November 2013 (UTC)
 Keep The property name is comprehensive. לערי ריינהארט (talk) 19:53, 14 November 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P742 ( pseudonym)

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 for keeping this, at least for the time being. Sven Manguard Wha? 04:45, 15 November 2013 (UTC)

pseudonym (P742): (delete | history | links | entity usage | logs | discussion) Same as above.--GZWDer (talk) 10:08, 8 November 2013 (UTC)

And my vote here is also  Keep until relevant datatypes are available. -- Lavallen (talk) 11:25, 8 November 2013 (UTC)
 Delete. See discussion above. Filceolaire (talk) 16:30, 8 November 2013 (UTC)
 Keep until multilingual datatype is unavailable. — Ivan A. Krestinin (talk) 19:48, 8 November 2013 (UTC)
 Keep The property name is comprehensive. לערי ריינהארט (talk) 19:55, 14 November 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P831

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 for keeping this, at least for the time being. Sven Manguard Wha? 04:46, 15 November 2013 (UTC)

parent club (P831): (delete | history | links | entity usage | logs | discussion) Merge parent club (P831) and parent organization (P749) to a new property "Parent organization".--GZWDer (talk) 05:22, 18 October 2013 (UTC)

 Keep, as "parent company" is usually defined by the law, whereas "parent organisation" is ambiguous and can mean anything from owners to a larger group that the item belongs to. --Wylve (talk) 08:50, 21 October 2013 (UTC)
 Keep per Wylve --Cekli829 (talk) 08:56, 8 November 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P160

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 for deleting this. Unfortunately it appears that it will have to be depreciated by hand as there's no one property that all of the current usages (around 1000 items) can be converted to. We can't delete this until it's properly depreciated, so GZWDer, Zolo, and Vogone, care to help?

As for parent club (P831), that will have to be nominated seperately, as it's not clear that everyone is commenting on both, and it would need to be explicit for me to delete it as part of this discussion. Sven Manguard Wha? 05:01, 15 November 2013 (UTC)

P160 (P160): (delete | history | links | entity usage | logs) Use owned by (P127), member of (P463), part of (P361) instead..--GZWDer (talk) 14:55, 17 October 2013 (UTC)

And can parent club (P831) also be deleted?--GZWDer (talk) 15:09, 17 October 2013 (UTC)
 Delete, owned by (P127), member of (P463), part of (P361) are indeed more accurate. The current usage of this property appears to be very inconsistent. --Zolo (talk) 20:44, 17 October 2013 (UTC)
 Keep Affiliation is not necessarily the same as being a member. An alliance need not imply control of one entity by another.--Jasper Deng (talk) 08:28, 1 November 2013 (UTC)
Not sure to see what you mean, neither member nor affilication tells anything about the degree of control. --Zolo (talk) 10:35, 1 November 2013 (UTC)
Delete. Use owned by (P127), member of (P463), part of (P361) instead and add a qualifier if you want to give a more nuanced description of the relationship. Don't make queries have to guess what type of relationship it is before they can retrieve the information. 86.6.107.229 20:44, 6 November 2013 (UTC) – The preceding unsigned comment was added by Filceolaire (talk • contribs).
Delete as per redundancy. Vogone talk 23:07, 7 November 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Several Star Trek characters have "affiliation --> Starfleet". What should we do to replace that? Employer works in that case, but not for Q (the character) where it's "affiliation --> Q Continuum" or Seven of Nine, who should (but doesn't) have "affiliation --> Borg". In all three cases, affiliation is a stand in for 'faction', but in the latter two cases, affiliation denotes fictional race while in the first it denotes occupation. Sven Manguard Wha? 06:00, 15 November 2013 (UTC)
I know very little about Star Trek, but if I understand correctly. "Q" is the name of both an individual and a species. So to keep it consistent with "instance of human". I would say that Q (individual) is an instance of Q (taxon), and per the discussion of fictional thing that Q (species) is an instance of fictional taxon. As for the Q continuum, it appears to be the place of origin of the Q (species) and I suppose we could have Q (individual): place of birth (P19) Q Continuum (Q2706873) or Q (species): endemic to (P183): Q Continuum (Q2706873)
The name of all induvidials of the Q-species are "Q", also the females. The most known female Q was acting as (male) homo sapiens helmsman on Enterprise and God in the last novell I read. -- Lavallen (talk) 10:20, 15 November 2013 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Properties_for_deletion/Archive/2013/3&oldid=1576015821"