Wikidata:Properties for deletion/Archive/2013/1

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

Property:P55

(Posting this here since there doesn't seem to be any more appropriate forum for it.)

This property is labelled "former member of sports team". Isn't the "former" aspect something that's supposed to be handled by qualifiers once they're available? I think this is probably redundant to Property:P54. --Yair rand (talk) 07:16, 5 February 2013 (UTC)

Yes, I was thinking it also. And here we can see the example: meta:Wikidata/Notes/Data_model_primer#Qualifiers. So yes, I support deletion. --Stryn (talk) 07:20, 5 February 2013 (UTC)

I just came to this item while translating, and I agree, it has to be deleted. Janjko (talk) 17:26, 5 February 2013 (UTC)

Should we wait until qualifiers are available or delete this now? --Stryn (talk) 18:15, 5 February 2013 (UTC)

I think it is better to delete it now, before it is used by many items, rather than correct them all later. --Beta16 (talk) 22:37, 5 February 2013 (UTC)

Done OK, I will remove and then delete this. James F. (talk) 22:40, 5 February 2013 (UTC) Now done. James F. (talk) 22:49, 5 February 2013 (UTC)

P60

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

This is a duplication of an "is a" relationship - it's used for saying things are stars, etc. Instead we want this to be a status of stars/etc. items, but that feature is to come later. James F. (talk) 17:55, 5 February 2013 (UTC)

Done --Morten Haan (talk) 18:46, 5 February 2013 (UTC)

Property:P67

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

This property should be of the 'date' type, not 'item'. Beta16 (talk) 19:00, 5 February 2013 (UTC)

At this time it seems not to be possible to choose that type. Conny (talk) 19:18, 5 February 2013 (UTC).

… and when it is, we do not need to delete the Property - we can alter the link type and use that. James F. (talk) 19:41, 5 February 2013 (UTC)

I'm not sure that we can change the data type of a property that already exists. I think we should not have this property yet, until the correct data type is implemented. --Beta16 (talk) 20:40, 5 February 2013 (UTC)

We actually can't change the type once it's been created... --Rs chen 7754 20:38, 5 February 2013 (UTC)

I suggest we delete the statements who link at this property, delete the property, and wait for the 'date' type to be implemented. There's no need to rush. --Sannita - not just another it.wiki sysop 22:20, 5 February 2013 (UTC)

Done. — Hazard-SJ ✈ 23:23, 5 February 2013 (UTC)

Property:P90

P90 (P90): (delete | history | links | entity usage | logs) It seems that this proverty is a duplicate of Property:P69. --Stevenliuyi (talk) 21:14, 5 February 2013 (UTC)

Done - Wiki13 _talk 21:16, 5 February 2013 (UTC)

... and cleaned up. James F. (talk) 21:19, 5 February 2013 (UTC)

Alma mater is usually associated with universities, it's strange to use it for highscools. Maybe I'm wrong. That's why I created the other tag. Janjko (talk) 21:38, 5 February 2013 (UTC)

I think it's more normally for Higher rather than Secondary education, yes, but not exclusively-so. James F. (talk) 21:40, 5 February 2013 (UTC)

Property:P64

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

empty and unused Beta16 (talk) 08:33, 5 February 2013 (UTC)

Um, that's not correct. --Yair rand (talk) 08:34, 5 February 2013 (UTC)

Correct, sorry. I've used RequestDeletion gadget that seems have some problem with Property namespace. --Beta16 (talk) 08:37, 5 February 2013 (UTC)

Done. --Stryn (talk) 08:41, 5 February 2013 (UTC)

Property:P66

Labelled "ancestral home", with the description "place of origin for Chinese people". I don't see how this could be useful as a property. --Yair rand (talk) 07:37, 5 February 2013 (UTC)

It's a basic property for Chinese people. Please take a look at en:Ancestral home (Chinese) for more information. Regards.--Stevenliuyi (talk) 08:00, 5 February 2013 (UTC)

So this attribute would be applied to Chinese individuals? Does the concept not exist for any other peoples? --Yair rand (talk) 08:09, 5 February 2013 (UTC)

Yes, it's only for Chinese.--Stevenliuyi (talk) 08:12, 5 February 2013 (UTC)

Request withdrawn. --Yair rand (talk) 11:12, 5 February 2013 (UTC)

Not done --Stryn (talk) 11:15, 5 February 2013 (UTC)

Property:P73

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

S'est enregistré avec la mention "Type de données : Fichier multimédia de Commons" alors que ce n'est pas ce que je voulais faire (?) Ljubinka (discussion) 10:57, 5 February 2013 (UTC)

Done. You set a wrong datatype, I guess. --Stryn (talk) 11:12, 5 February 2013 (UTC)

Property:P10

The same as Property:P18 dega180 (talk) 11:07, 5 February 2013 (UTC)

Not done. We can't delete it (yet). See also Property talk:P10, Wikidata:Property_proposal#Image_.2F_Abbildung_.2F_Image, Wikidata_talk:Property_proposal#Commons_media_file. --Stryn (talk) 11:13, 5 February 2013 (UTC)

Property:P79

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

Duplicate of P48 MichaelSchoenitzer (talk) 11:59, 5 February 2013 (UTC)

Done --Morten Haan (talk) 15:34, 5 February 2013 (UTC)

Somewhat confused as to what happened here. Could someone please explain? — PinkAmpers&^{(Je vous invite à me parler)} 20:47, 5 February 2013 (UTC)

I try: MichaelSchoenitzer marked property:P79 for deletion, but because gadget does not work correctly, it added Q79 here. Then Morten Haan deleted Q79, but I don't know why he didn't checked if it's a wrong link. Then I restored Q79 when I noticed it was deleted. Log. --Stryn (talk) 20:53, 5 February 2013 (UTC)

Ahh. So should we now discuss whether or not Property:P79 P79 (P79): (delete | history | links | entity usage | logs) should be deleted? — PinkAmpers&^{(Je vous invite à me parler)} 22:09, 5 February 2013 (UTC)

I guess that's the intention. See Property talk:P48#Datatype as well. — Hazard-SJ ✈ 23:29, 5 February 2013 (UTC)

Oops, before you commented, I had deleted as a blank page/duplicate of P48. If you want to undelete, be my guest. Regards, — Moe Epsilon 23:31, 5 February 2013 (UTC)

Went ahead and restored, sorry :) Regards, — Moe Epsilon 23:35, 5 February 2013 (UTC)

Congratulations! I was going to restore, but I found a bug and stopped to report it. — Hazard-SJ ✈ 23:43, 5 February 2013 (UTC)

Well that is strange, I checked the last revision before I undeleted and didn't see this bug. At least my hastiness has found us a bug :) Regards, — Moe Epsilon 23:45, 5 February 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I just made a check and it seemed it was only because you restored before the version was loaded for me, so it turns out it isn't really a bug. It'd be nicer if the interface was more specific, though. — Hazard-SJ ✈ 23:53, 5 February 2013 (UTC)

Well {{facepalm|supreme}} Regards, — Moe Epsilon 23:57, 5 February 2013 (UTC)

Well, Property:P48 has the Commons media file datatype covered, and Property:P85 has the item datatype covered, and since P85 has labels in far more languages, I think it's safe to assume that it's more widely used than P79. Any reason not to delete? — PinkAmpers&^{(Je vous invite à me parler)} 04:54, 6 February 2013 (UTC)
Done, per PinkAmpersand. — Hazard-SJ ✈ 04:59, 6 February 2013 (UTC)

Property:P95

Per discussion, date of birth will be done using TimeValue not Items. Del_♉sion23 (talk) 00:43, 7 February 2013 (UTC)

Done - will inform the creator. James F. (talk) 00:45, 7 February 2013 (UTC)

Property:P104

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

I made it without realizing that the necessary datatype is not supported yet. Sorry about that. Soulkeeper (talk) 18:27, 8 February 2013 (UTC)

Done James F. (talk) 18:27, 8 February 2013 (UTC)

Property:P53

Labelled "Noble family". I don't see what use this could have. --Yair rand (talk) 07:26, 5 February 2013 (UTC)

Maybe something to do with European royalty? --Rs chen 7754 07:38, 5 February 2013 (UTC)
You mean like "United Kingdom > Noble famlily : British Royal Family" ? --Yair rand (talk) 07:58, 5 February 2013 (UTC)
Partially - a few centuries ago there were intermarriages between royalty of different countries, I believe. --Rs chen 7754 08:18, 5 February 2013 (UTC)
I ment to noble families by country. It can be usful for templates of Nobility ect. In same cases it called "House of ...". Geagea (talk) 18:44, 5 February 2013 (UTC)
I still do not see what it means exactly in Q3652004. --Zolo (talk) 14:37, 6 February 2013 (UTC)
It means that Giorgi Avalishvili is part of Avalishvili princely family (or noble family). --Stryn (talk) 14:49, 6 February 2013 (UTC)
If this is how it is meant to be used, I do not see the point of adding "noble". But sorry, I meant Q4055316 (or is that one just a mistake ?). --Zolo (talk) 14:59, 6 February 2013 (UTC)
Two ways of using. First, members of the noble family will be connected to this ticket. second, noble families can have the ticket by country - Georgian noble family, German noble families ect. Geagea (talk) 01:04, 7 February 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘I believe we've been generally avoiding having properties that can be used for multiple types of entity. I'd Oppose deletion, since I think it could have some use for items on individuals, though it might need to be renamed. For items on countries, though, I think we'd need a separate property - "ruling house", perhaps? (I don't think there's much point in trying to sort out the houses themselves by nation, since in the majority of cases there's no one answer - the Mountbatten-Windsors have at various points ruled over a dozen European states.) — PinkAmpers&^{(Je vous invite à me parler)} 12:14, 7 February 2013 (UTC)

Yes, using the same property for two logically different relations does not sound a good idea. A property to mean "member of family" may be ok, though I think we will have to define it better at some point.--Zolo (talk) 09:37, 8 February 2013 (UTC)

O.K, I tried to remove the tag from Q4055316 but unsuccessfully. Geagea (talk) 23:29, 8 February 2013 (UTC)

I removed the tag from [[Avalishvili. Geagea (talk) 00:12, 9 February 2013 (UTC)

Thanks, I think we can close as keep for now, and perhaps have more thoughts about it once things are a bit more advanced ? --Zolo (talk) 10:22, 11 February 2013 (UTC)

Not done per discussion above. --Stryn (talk) 18:36, 11 February 2013 (UTC)

Property:P62

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

dub of Property:P18 (image) --ThorstenX1 (talk) 11:50, 10 February 2013 (UTC)

Done per comments here and here. --Stryn (talk) 15:14, 10 February 2013 (UTC)

Property:P124

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

Empty, not used. --Kolja21 (talk) 23:41, 18 February 2013 (UTC)

Done - we don't have the proper datatype for this right now. Sven Manguard Wha? 23:46, 18 February 2013 (UTC)

Property:P125

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

Empty, not used. --Kolja21 (talk) 23:41, 18 February 2013 (UTC)

Done - we don't have the proper datatype for this right now. Sven Manguard Wha? 23:46, 18 February 2013 (UTC)

P130

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

Incorrect datatype JAn Dudík (talk) 20:47, 20 February 2013 (UTC)

Done Legoktm (talk) 20:59, 20 February 2013 (UTC)

Property:P68

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

Discussions are ongoing

"Municipality" is a property from the list "Added without discussion" (Wikidata:List of properties). Rarely used and with an example that is not convincing: "<Statue of Liberty> municipality <New-York>". --ThorstenX1 (talk) 12:04, 13 February 2013 (UTC)

I suggested it, but somebody other did it: Wikidata:Property_proposal#Municipality_.2F_Gemeinde.2F_Commune. --Stryn (talk) 12:08, 13 February 2013 (UTC)

Should we move it to "Place" with the remark: "<Do not use> municipality <, it is still under discussion>"? --ThorstenX1 (talk) 12:31, 13 February 2013 (UTC)

I don't know why we should not accept this. E.g. In Finland we have 320 municipalities. --Stryn (talk) 12:58, 13 February 2013 (UTC)

We can change its name by location, it might be more meaningful. --Jitrixis (talk) 21:49, 13 February 2013 (UTC)

Municipality should be kept, many countries use it.--Lam-ang (talk) 06:32, 14 February 2013 (UTC)

I am the creator of this property, sorry if I created this property without discussion but I did not know that I had to do so. I think that this property is important to describe the location of objects that are in countries that use municipalities.--dega180 (talk) 00:50, 15 February 2013 (UTC)

For example in Italy I can't immagine how to describe the location of a museum that is in a small town with 1000 people this is not a city!--dega180 (talk) 00:55, 15 February 2013 (UTC)

@Dega180: For this you will need a property "location", not city or municipality. --Kolja21 (talk) 03:39, 15 February 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Ok but "location" can means: "a mountain", "an island", "a municipality", a "frazione", "a Neighbourhood", "a park", ecc. instead "municipality" means one thing and therefore data are more uniform. In it.wiki (I know that this is an international wikitata and not an italian wikidata) it's standard to use "municipality" when you want to describe the location of an object and I think that is so also in wikies use a language spoken in countries that use municipalities. Sorry if my English is bad--dega180 (talk) 09:20, 15 February 2013 (UTC)

The Statue of Liberty is located in the city (Property:P83) New York. And it will be hard to find the right municipality for Yosemite National Park. "Municipality" is not a thing like a tree, it's an administration term, and it's meaning changes from country to country. We need a concept for this kind of terms. Saying "A municipality B" can mean anything. A lived, died, worked, have an job in B. --Kolja21 (talk) 23:28, 15 February 2013 (UTC)

Municipality is a necessary parameter, since it is a Third-level administrative country subdivision in many countries. I suggest that as alias of the parameter, or we rename it "3rd level adm country subdivision". Infoboxes for localities in for example Swedish Wikipedia have a parameter called "kommun" (i.e. municipality). In English Wikipedia, the {{:en:template:infobox settlement|infobox settlement}} has solved it in a generic but complicated way, making it possible to use the same infobox both for municipalities, cities and other localities, by using three parameters: settlement_type (e.g. city or municipality), subdivision_type3 (e.g. = Municipality if the settlement belongs to a municipality); and subdivision_name3 (e.g. Gothenburg municipality). I would prefer that we have different properties for different second and third administrative country subdivisions, etc.

In Sweden, each municipality is a merge of several historical "socknar" (civil parishes), and may contain several rural areas as well as country-side villages. Each municipality belongs to one and only one county or region ("län"), i.e second level administrative country subdivision. The term municipality is often confused with city, but Gothenburg city is only part of Gothenburg municipality. The largest settlement in each municipality is often but not always a former city (today cities have no legislative definition in Sweden). Mange01 (talk) 16:46, 18 February 2013 (UTC)

Right now there are 10 subdivision properties for a country: Wikidata:List of properties#Country: subdivisions. --Kolja21 (talk) 19:21, 18 February 2013 (UTC)

But nothing appropriate to small towns, and also for cities, what does it mean City? How many hinabitants a living center needs to be considered a "city"? And how many hinabitants a living center needs to be considered a Town? The other subdivision proprerties for a country are not precise, the only precise property is municipality that in many country is defined in a precise way by law.--dega180 (talk) 20:14, 18 February 2013 (UTC)

I suggest that we use some international ontology specification in this case, for example the GeoNames ontology. See http://www.geonames.org/statistics/total.html . Municipalities are called "second-order administrative division" in that document, while the enwp category is called "second-level administrative country subdivisions". Regarding Dega180:s question on P83: GeoNames uses the term "Populated Place" for a city, town and village. Enwp infoboxes groups these terms into "settlement". Mange01 (talk) 22:24, 18 February 2013 (UTC)

Good suggestion. I've changed Property:P33 (now: settlement) so we can merge it with Property:P83 ("city, relatively large and permanent settlement"). Likelihood of confusion: Where is the difference between the municipality New York City (Statue of Liberty, "head of municipal government": Michael Bloomberg) and the settlement New York City? Should we change "head of municipal government" (Property:P6) to "head of local government"? --Kolja21 (talk) 03:01, 19 February 2013 (UTC)

I Think must be different propoerties for municipality (administrative level with head of execitive) and for settlement (village, hamlet, town). In Czech republic is 6252 municipalities and about half of them consists of several settlements. JAn Dudík (talk) 12:30, 19 February 2013 (UTC)

I changed my opinion, I agree to delete because was created Property:P131.--dega180 (talk) 10:22, 21 February 2013 (UTC)

While we had a nice talk here, there have been made the decision to declare all administrative divisions as DEPRECATED (Wikidata:List of properties). There are two new items (located in administrative unit, type of administrative division) and hopefully later a description and examples how to use these properties will follow. Link to one of the other discussions on this topic: WD:PC#Administrative divisions again - hopefully, last topic. --Kolja21 (talk) 23:45, 21 February 2013 (UTC)

I moved all P68 in P131, so if there is consensus I can delete it. --ValterVB (talk) 21:52, 23 February 2013 (UTC)

Done as deprecated and unused. If you feel it necessary to undelete, let me know and I can. Regards, — Moe Epsilon 16:03, 24 February 2013 (UTC)

Property:P83

P83 (P83): (delete | history | links | entity usage | logs) Deprecated, unused Magnus Manske (talk) 15:11, 24 February 2013 (UTC)

Done as deprecated. If you think there may be a reason to restore, let me know and I can undelete. Regards, — Moe Epsilon 15:58, 24 February 2013 (UTC)

Property:P28

Done as deprecated. If you think there may be a reason to restore, let me know and I can undelete. Regards, — Moe Epsilon 16:00, 24 February 2013 (UTC)

Property:P33

P33 (P33): (delete | history | links | entity usage | logs) Deprecated, unused Magnus Manske (talk) 15:12, 24 February 2013 (UTC)

Done as deprecated. If you think there may be a reason to restore, let me know and I can undelete. Regards, — Moe Epsilon 16:00, 24 February 2013 (UTC)

Property:P68

P68 (P68): (delete | history | links | entity usage | logs) Deprecated, unused Magnus Manske (talk) 15:12, 24 February 2013 (UTC)

Done as deprecated. If you think there may be a reason to restore, let me know and I can undelete. Regards, — Moe Epsilon 16:02, 24 February 2013 (UTC)

Property:P93

P93 (P93): (delete | history | links | entity usage | logs) Deprecated, unused Magnus Manske (talk) 15:13, 24 February 2013 (UTC)

Done as deprecated. If you think there may be a reason to restore, let me know and I can undelete. Regards, — Moe Epsilon 16:03, 24 February 2013 (UTC)

Property:P34

P34 (P34): (delete | history | links | entity usage | logs) Deprecated, unused Magnus Manske (talk) 15:46, 24 February 2013 (UTC)

Done as deprecated. If you think there may be a reason to restore, let me know and I can undelete. Regards, — Moe Epsilon 15:56, 24 February 2013 (UTC)

Property:P12

P12 (P12): (delete | history | links | entity usage | logs) Deprecated, unused Magnus Manske (talk) 17:30, 24 February 2013 (UTC)

Done Lukas²³ ^talk in German ^Contribs 17:40, 24 February 2013 (UTC)

Property:P11

P11 (P11): (delete | history | links | entity usage | logs) Deprecated, unused Magnus Manske (talk) 18:16, 24 February 2013 (UTC)

Done - Wiki13 _talk 18:19, 24 February 2013 (UTC)

Property:P151

P151 (P151): (delete | history | links | entity usage | logs) Should be an integer, but I am unable to make such a type. Danrok (talk) 20:22, 24 February 2013 (UTC)

Done, pure integer values are not yet available. IW 20:39, 24 February 2013 (UTC)

Bulk deletion request

Property:P152 (delete | history | links | logs)
Property:P153 (delete | history | links | logs) (all on TAB)

should have been datatype string, not item. see also diskussion page. --Goldzahn (talk) 06:54, 25 February 2013 (UTC)

Done Jon Harald Søby (talk) 10:42, 25 February 2013 (UTC)

Property:P31 "is a"

Not done Ajraddatz (Talk) 20:50, 25 February 2013 (UTC)

Property:P192

P192 (P192): (delete | history | links | entity usage | logs) Just an experiment. Mange01 (talk) 20:10, 3 March 2013 (UTC)

Done --Zolo (talk) 20:16, 3 March 2013 (UTC)

Property:P203

P203 (P203): (delete | history | links | entity usage | logs) Wrong property type -- Docu at 00:42, 6 March 2013 (UTC)

Done-- DangSunM (T · C) 00:57, 6 March 2013 (UTC)

Property:P211

P211 (P211): (delete | history | links | entity usage | logs) Just testing strings Aude (talk) 16:06, 7 March 2013 (UTC)

Done If you want to restore it please tell me.-- DangSunM (T · C) 16:08, 7 March 2013 (UTC)

Property:P172

Property added without discussion. Only language he: לאום, what means "nation". The "nation" of Benjamin Netanyahu is - according to the use of the property - "Jews", and the "nation" of Yasser Arafat is "Arab people". The correct perperties would be country of citizenship (P27) and religion (P140). --Kolja21 (talk) 23:55, 1 March 2013 (UTC)

Based on the usage of the property, I guess what the creator wants is something like "ethnic group", which can not be replaced by P27 or P140. For example, there are ethnic Jews who don't believe in the religion of Judaism, and there are practitioners of Judaism who are not ethnically Jewish. --Stevenliuyi (talk) 06:48, 2 March 2013 (UTC)

This is an interesting example of the limits of a multilingual project. This property has been created in Hebrew, with a short description, and translated into Czech - these two languages are not universally understood, and I don't understand either of them. We can hope that the Czech translation of the Hebrew original is a precise equivalent, we can also fear that it is an approximate translation : I can see that czwiki národ is interlinked to enwiki "Nation", but that the hewiki interlink for "nation" is something different from "לאום". In such obscurity, I don't think it is possible to have an opinion on this, positive or negative. How will that be solved ? I keep it in watchlist and shall see how it goes on. Touriste (talk) 08:29, 2 March 2013 (UTC)

I suppose "ethnic group" is important for cultural workers from multicultural countries, e.g. Taras Shevchenko Citizenship = Russian Empire, used languages = Ukrainian and Russian but he is known as Ukrainian poet --AS (talk) 09:32, 2 March 2013 (UTC)

Somewhat related discussion at Wikidata:Property_proposal#Unrecognized_country_of_citizenship.

An "ethnicity" property seems unavoidable (though, as a Frenchman, I am culturally biased against it...) --Zolo (talk) 10:27, 2 March 2013 (UTC)

Aryan and "half-Jewish" included? I think we should have some basic standards for POV properties. --Kolja21 (talk) 17:30, 2 March 2013 (UTC)

1. Rudy Giuliani is a good example, an Italian with U.S. Citizenship. So to him one parameter and one parameter citizenship and nationality / ethnicity. It's two different parameters each one says something different.

2. and this is definitely a good example of a wiki project common to all languages. Good things come out of it with God's help.

3. Sorry for my English .. This translated using Google Translate .. I relatively understand, but not to write

אבגד (talk) 07:20, 3 March 2013 (UTC)

Thanks you for your reply. As Kolja says, such a property can have tricky political implications, Even in cases like Rudy Giuliani, things are not very simple : he has lived all his life in the United States and is part of the US national political establishment. Not everyone would agree that he can be considered Italian just because his parents were born in Italy. This property will certainly need further discussion before we know if we can implement it, and how it should be done. --Zolo (talk) 10:54, 3 March 2013 (UTC)

Michael Bloomberg for example, is a better example, because he defines himself as a Jew and his citizenship is the United States. It should be the two parameters that each parameter has a different meaning. אבגד (talk) 23:50, 3 March 2013 (UTC)

I think we can keep this as "ethnicity" but, absolutely, we will want to demand a very high bar for proof before it is used. James F. (talk) 06:23, 4 March 2013 (UTC)

I would postpone it until we have decent general sourcing and possibly also privacy guidelines. --Zolo (talk) 07:28, 5 March 2013 (UTC)

Done DangSunM (T · C) 16:10, 9 March 2013 (UTC)

Use for this property ... In the Ottoman empire, people who were Bosnians, or Serbs or Albanians became Grand Vizier.. At that time there were no countries and it is relevant to indicate their ethnicity. GerardM (talk) 13:59, 22 October 2013 (UTC)

Property:P292

P292 (P292): (delete | history | links | entity usage | logs) Wrong data type (should be QuantityValue). --Kolja21 (talk) 14:18, 18 March 2013 (UTC)

Done If you want to restore, please tell me --DangSunM (talk) 15:14, 18 March 2013 (UTC)

Property:P165

P165 (P165): (delete | history | links | entity usage | logs) Duplicate. MichaelSchoenitzer (talk) 14:29, 19 March 2013 (UTC)

Done If you want to restore, please feel free to ask.--DangSunM (talk) 14:32, 19 March 2013 (UTC)

Comment. This property is still in use in Q12418, because, for some unidentified reason, it cannot be removed (already notified in bugzilla). --Zolo (talk) 14:37, 19 March 2013 (UTC)

Now I just restored and redeleted--DangSunM (talk) 14:39, 19 March 2013 (UTC)

I tried to that way, but not removed.--DangSunM (talk) 14:48, 19 March 2013 (UTC)

Yes that is bugzilla:45933. I think that the property can be removed nonetheless, as it may be confusing to keep a deprecated property. --Zolo (talk) 15:02, 19 March 2013 (UTC)

Property:P97 (Noble title)

noble title (P97): (delete | history | links | entity usage | logs | discussion) Was created without discussion and from the (brief) discussion here, I suggest this be deprecated and deleted before it's used too much and we wait for the MultilingualText property value so that uses of the new property are accurate and can be translated. /Ch1902 (talk) 16:15, 23 March 2013 (UTC)

Done Please ask for undeletion if needed. Regards, Vogone talk 17:18, 23 March 2013 (UTC)

Property:P222

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. --Izno (talk) 17:46, 29 March 2013 (UTC)

P222 (P222): (delete | history | links | entity usage | logs) It was created without a discussion. The datatype is wrong, it should be MultilingualText not String, because it contains real text and Wikidata is multilingual not English. We should delete quickly it before it is used to much and tons of useless work is spent using it. -- MichaelSchoenitzer (talk) 00:44, 8 March 2013 (UTC)

Strong delete I'm not sure if this would even be useful if it were of the right datatype (it's far more vague than most properties), but it should be deleted as the wrong datatype regardless. I'm only not doing this myself because there's always some nuances in properties, so it's best to wait for some discussion before deleting. — PinkAmpers&^{(Je vous invite à me parler)} 01:40, 8 March 2013 (UTC)

See Property talk:P222 for the listing on Wikidata:Property_proposal prior to creation. It was part of a series of infobox items.

As mentioned on its talk page, it can easily be converted to a multilingual text once these are available.

BTW, please avoid breaking its description while it's listed here. -- Docu at 05:28, 8 March 2013 (UTC)

Ummm... last I checked it was technically impossible to change a property's datatype. And I didn't "break" the description, I saved us a lot of work orphaning this property if it winds up getting deleted. — PinkAmpers&^{(Je vous invite à me parler)} 06:29, 8 March 2013 (UTC)

How do you want to convert it to MultilangualText? 1. There is no technical possibility to change the datatype of a property. Only way would be creating a new one and writing a bot that transfers all the data. 2. What if someone uses his language instead of English now, than the string can't be converted automatically at all. Someone would have to check all uses manually. Sorry, but I don't believe these problems are worth of not having to wait for 2 weeks until Multilangual String is ready. It may even double the work to be done. -- MichaelSchoenitzer (talk) 11:50, 8 March 2013 (UTC)

Good thing someone volunteered to do it on the item's talk page shortly after its creation. -- Docu at 03:49, 9 March 2013 (UTC)

What we're trying to tell you that it's literally impossible to change property types; to manually convert them we'll still need to orphan this property, delete it, create a new one, and re-add the statements. In other words, we'll have to delete it no matter what. So unless someone wants to argue that P222 and P224 should be monolingual, not multilingual, I plan on deleting these before any more damage is done. — PinkAmpers&^{(Je vous invite à me parler)} 04:50, 9 March 2013 (UTC)

I don't quite understand what damage has been done?

As for the conversion, Michael explained how it's to be done. Once it has been completed in can indeed be deleted. I'm not sure you should be deleting it though as you participated in the discussion. -- Docu at 07:30, 9 March 2013 (UTC)

The damage is that the longer the property's out there, the more claims will get added using it, which is more we'll have to change later on. So, to be clear: You agree that the property, with the current datatype, should be deleted? — PinkAmpers&^{(Je vous invite à me parler)} 12:14, 9 March 2013 (UTC)

How do you want to do the conversion? Using a bot? Then do you have a working bot? And how do you want to make sure if the text given is English? Or manually? Then I don't see what use the property now should have, if you will have to do all the work again. -- MichaelSchoenitzer (talk) 13:45, 9 March 2013 (UTC)

Support per PinkAmpersand. James F. (talk) 21:40, 9 March 2013 (UTC)

We don't have a tool to change a property right now. The right way to go seems to be to create a new property, then move all statements that can be moved from using the old property to using the new property for each and every item, then possibly delete the remaining old statements and possibly also the old property. The middle subsentence is the actual tool. Such a tool should be a special page, or some work list you can page over, and not a bot. If it automates a lot of changes it should only be available for admins.

In this case it seems to me that the property is a bit vague. Is it a loose description, is it statistical property, or is it actual periods in the past the lake has been frozen. If it is the last two, then you should use the time type. It can be used to describe a time interval, well sort of. And I'm not sure when it will be available. — Jeblad 15:33, 9 March 2013 (UTC)

Comment FWIW, some discussion of this parameter at en:Template talk:Infobox lake/Archive 1#New fields/variables for infobox. Perhaps a discussion on that infobox is needed to clarify the types of time frames and multilanguage representations, if this info is potentially suitable for Wikidata. Dl2000 (talk) 02:56, 13 March 2013 (UTC)

Since there hasn't been anymore discussions and all except for the creator are for deletion, I would ask an admin for deletion for this property. -- MichaelSchoenitzer (talk) 21:53, 19 March 2013 (UTC)

I see the problem with this property and that it will sooner or later be deleted, but when you recreat it, please allow it to be used also for other kinds of water than just lakes. -- Lavallen (block) 16:16, 20 March 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:P224

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 should be deleted. --Izno (talk) 18:24, 29 March 2013 (UTC)

P224 (P224): (delete | history | links | entity usage | logs) It was created without a discussion. The datatype is wrong, it should be MultilingualText or Item but not String, because names of lake sections can diver in different languages. We should delete quickly it before it is used to much and tons of useless work is spent using it. -- MichaelSchoenitzer (talk) 00:44, 8 March 2013 (UTC) MichaelSchoenitzer (talk) 00:44, 8 March 2013 (UTC)

Comment Based on the contents of your nomination, I've changed this from P:P223 to P:P224. If you'd like to nominate P223 as well, though, that might be a good idea, as I see there's already discussion of whether it should be multilingual or not.

Oh, and, for what it's worth,

Support deletion per my comments in the section above. — PinkAmpers&^{(Je vous invite à me parler)} 01:47, 8 March 2013 (UTC)

See Property talk:P224 for the listing on Wikidata:Property_proposal prior to creation. It was part of a series of infobox items.

As mentioned on its talk page, it can easily be converted to a multilingual text once these are available.

BTW, please avoid breaking its description while it's listed here. -- Docu at 05:31, 8 March 2013 (UTC)

Support deletion per PinkAmpersand. James F. (talk) 21:40, 9 March 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:P49

P49 (P49): (delete | history | links | entity usage | logs) Unless we import the Wiktionary here, items are for concepts not for words. "What links here" show that in its current state, the property produces non-sensical results. If we want to have this sort of info, we should use the string datatype (probably one property per language). In its current state, it just does not work Zolo (talk) 17:25, 3 March 2013 (UTC)

Oppose Tricky case. Property:P49 corresponds to en:category:Demonyms, which includes several list articles, making it useful for phase 3. It is also related to the (unused) template Demonym country, making it relevant to phase 2. It seems possible for a bot to aggregate data from Wikipedia. Already now, someone has added a few dozen countries. Mange01 (talk) 19:06, 3 March 2013 (UTC)

Orphan, delete, and create new property of "MultilingualTextValue" datatype when possible. Links to items like "Spanish people" for Spain can be done under properties with names like "inhabited by" or "main ethnicities". — PinkAmpers&^{(Je vous invite à me parler)} 21:36, 3 March 2013 (UTC)

... then why not just re-label it to "major ethnicity"? James F. (talk) 06:25, 4 March 2013 (UTC)

I'd be fine with that, if someone would first check for all cases where the object would no longer be valid (e.g. "Americans" for the US). — PinkAmpers&^{(Je vous invite à me parler)} 12:30, 4 March 2013 (UTC)

This is normally not an ethnical group, but a name of all citizens. The text datatype is not a good option, bucause texts are not linkable, it is not possible to produce list articles from them, it is hard to auto-translate without manual work, and they do not contribute to building a machine-readable ontology. Are names missing for some countries? Then we can wait for acceptance of redirected subjects as items, or of wiktionary items. Mange01 (talk) 07:57, 5 March 2013 (UTC)

Reduction whilst we wait for new data types (but they won't be here for at least a month or so). James F. (talk) 06:25, 4 March 2013 (UTC)

weak

Support. It worth not only a multilingual string but a well-developed dictionary structure (in some languages demonym is gender- and mb sth-else-dependent). Currently it collects items of too different kinds. You see, there are very few demonyms notable in Wikipedia. Mb it would be better to create backward field "demonym of", which is attached clearly to demonyms themselves. But this one on current stage obviously it's better to delete then to dig out pearls in what it is. Ignatus (talk) 17:07, 11 March 2013 (UTC)

Just my small exploration of 5 first resulth of WLH:

Spain ~ Spaniards: major ethnicity, not demonym ea
Austria ~ Austrians: major ethnogeographical group
Greece ~ Greeks: major ethnicity
Turkey ~ Turkish people: major ethnicity
France ~ French people: major ethnicity

Now first appeared countries which are not so strong 1-1 associated with any ethnical group:

Great Britain ~ British people: people of citizenship and nationality (amn't shure what does the last word mean in English)
Russia ~ Rossiyane: members of society of citizens (most close to the concept of "demonym", term specially invented for such cases)
Bosnia and Herzogovina ~ Bosnjaki (major ethnicity of a region) and Herzogovinci (people of a region, demo- but not -nym and for Herzogovina): not a demonym ea which must be single word, gender/social-dependent or has several sinonyms
DPRK ~ Koreans: major ethnicity which obviosly lives also in Q884, and all over the world more
EU ~ European people: disambig (I know these items are allowed, but how are they allowed for meaningful properties?)
UAE ~ Emirati people: citizens and an ethnic group (demo- but not -nym)
USSR ~ Soviet people: umbrella demonym (finally a true demonym! "rossiyane" is it's "cut" version)

I won't discuss here administrative subdivisions but soup there is even worse including lists of notable people, major ethnicities etc. I can't see here cities whichs demonyms are (dictionary) notable linguistic concepts in Russian. I remarked support to deletion as weak since 1) there are from 1 to 4 true demonyms in list of 11-13 elements inspected and 2) maybe we can rename it to major ethnicity and clear the rest. Ignatus (talk) 20:37, 12 March 2013 (UTC)

Deleted, as shown by Igatus, usage was really inconsistent, and sometimes non-sensical. Ethnicit can be started as a new property, but that is not the same thing. Large-scale creation of items about words might be possible, but would required careful thinking in a multilingual encyclopedia. Note that some pages are still linked to this property because of bugzilla:45933 --Zolo (talk) 15:28, 28 March 2013 (UTC)

Property:P363

P363 (P363): (delete | history | links | entity usage | logs) Wrong data type, see Wikidata:Property_proposal/Pending GZWDer (talk) 05:16, 29 March 2013 (UTC)

Done Not against undeleting, but since it was created in error, without discussion and only added to a couple items, it could be deleted. If you want to restore, just let me know. Regards, — Moe Epsilon 07:10, 29 March 2013 (UTC)

Property:P362

P362 (P362): (delete | history | links | entity usage | logs) Wrong data type, see Wikidata:Property_proposal/Pending GZWDer (talk) 05:17, 29 March 2013 (UTC)

Done Not against undeleting, but since it was created in error, without discussion and only added to a couple items, it could be deleted. If you want to restore, just let me know. Regards, — Moe Epsilon 07:10, 29 March 2013 (UTC)

"Type of" 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. It seems that P:P31 and P:P279 are more suited for all of the following. That would avoid the creation of many niche properties, and allow the distinction type of / subclass of".

Property ID	Label	Description
P60	astronomical object	type of astronomical object, e.g. planets, extrasolar planets, dwarf planets, natural satellites, comets, asteroids, brown dwarfs, stars, galaxies, quasars
P132	type of administrative division	is an administrative division such as a U.S. state, Italian commune or second-level administrative unit
P168	structure type	structure type or intended primary function according to structural characteristics, e.g. bridge, airport terminal. May be mapped to :en:template:infobox building -> building type.
P173	type of election	type of political election, e.g. general election, presidential election
P202	lake type	type of lake, e.g. reservoir, glacial lake, periglacial, subglacial, artificial reservoir, endorheic, meromictic, oxbow, rift lake, underground, crater lake, intermittent, former lake, shrunken lake; oligotrophic, mesotropic, eutrophic, hypertrophic
P288	watercraft type	types of boats, ships, hovercraft and submarines
P302	mountain type	type of mountain

The main reason I would see to keep the current properties would be that they are easier to use in infoboxes. But I seems impossible to create on "type of" properties for each type of different infobox in all Wikipedias.

That should be decided quickly before those properties get used for real in Wikiipedias. --Zolo (talk) 14:56, 28 March 2013 (UTC)

Just a note on the listing: somehow the labels in your post don't match properties ids you listed. -- Docu at 21:26, 28 March 2013 (UTC)

Oops, hasty copy-paste, fixed. --Zolo (talk) 22:13, 28 March 2013 (UTC)

Personally, I think the main advantage of, e.g. Property:P132 (administrative division), is that it allows to determine (a) that a given item is an administrative division and (b) which level of administrative definition. -- Docu at 21:26, 28 March 2013 (UTC)

That was the certainly initial idea, but it turns out that it is not so convenient. There are potentially many many of them, and it may become hard to find the right one. For instance, I have seen P31 used for P132 (and it probably makes sense) Also, not all items can fall neatly into one and only one "type of", which may create many gaps and overlaps. For instance, I was wondering if French cantons should use P132. Wikipedia often seems to consider them as administrative divisions, but in fact they are rather electoral districts, so that would not be technically correct. If we replace that by "instance of: French canton", those who know a bit about the subject will understand what it is about, others may need to follow one link, but that is still ok. For more automated tasks, we would certainly need to put the sub-class into good use, and devise tools and modules to make the most of it. --Zolo (talk) 22:13, 28 March 2013 (UTC)
- Hmm .. Are there samples were just P31 already works for something? -- Docu at 04:44, 29 March 2013 (UTC)
  - I do not think it is in use yet. But a subclass tree + instances would do the same things as "type of", and sum of all possible type ofs. Suppose you want to get a list of bridgse in Iowa. It would be straightforward with subclass / instance. In contrast with "type of", you could write "type of structure: bridge", in all bridges's items. But, as "bridge may not be precise enough for many other uses, you would also need a "type of bridge" property, and so on ad libitum. Of course, we could also keep both systems at the same time, but I do not think it is a good idea. In the long term, it should not provide any benefit, and maintaining two equivalent systems would make things more confuse and would impose substantial maintenance overheads. --Zolo (talk) 16:01, 29 March 2013 (UTC)
    - - I think the "structure" might be a bit different from the other ones as one rarely searches just for a type of "structure" (IMHO, I know there are websites just about that). For many others, it might get confusing if you can search for the same item in both "instance of" and "type of" (e.g. meromictic lake). -- Docu at 04:13, 3 April 2013 (UTC)

Yes, just 1 'instance of' and 1 'subclass of' will be sufficient, together with other properties of an item that describe the context. So future queries will be possible. RobotMichiel1972 (talk) 23:14, 28 March 2013 (UTC)
Comment My two cents: advantage in having one property: is more simple to make queries. But we'd take advantage in having more properties if in the future will be implemented a sort of mechanism to limit their allowed values. I don't know which solution is the best, but here we already discussed to limit its use creating more specific properties. Now, after changing the name of P31 in instance of, it is proposed to return to one "type of" property. Imho we need to decide quickly and definitively. --Paperoastro (talk) 23:20, 28 March 2013 (UTC)

Yes, if we dont want the "type of" property we have to decide it before widespread Wikipedia usage, but note that if those properties are useful after all, recreating it will not cause as many problems. I do not think P31 should be renamed, just that we should use "instance of church" rather than "type of building: church". --Zolo (talk) 06:54, 29 March 2013 (UTC)

Support. When trying to explore items of a certain type with, say, queries, which would you prefer: having to know a huge number of arbitrarily-named properties, or just two? The nominated properties are all redundant with instance of (P31) and subclass of (P279). While P31 and P279 have an established basis in recommendations from the W3C on how to represent knowledge in the Semantic Web, I am not aware of any knowledgebases that use a proliferation of domain-specific type properties. Emw (talk) 00:40, 29 March 2013 (UTC)
- Comment, it doesn't have to be something similar to that what you're calling 'domain-specific type' property (nice wording by the way). It just have to fit our purposes best. --Nightwish62 (talk) 22:19, 31 March 2013 (UTC)
Oppose. P31 and P279 are experimental properties and might be useful one day, but they shouldn't replace properties that have a clear definition. Deleting these properties would complicate the use of Wikidata in templates and infoboxes. "Type of building" (P168) is used for example in w:en:Template:Infobox building and w:fr:Modèle:Infobox Monument. --Kolja21 (talk) 02:25, 29 March 2013 (UTC)

Actually "building" is far from having a clear definition. In any case, we can get the "type" paramter of w:en:Template:Infobox building using the subclass structure. I'll try to build a real-world implementation, but I wont have much internet connection in the next few days. --Zolo (talk) 16:01, 29 March 2013 (UTC)
What do you mean by "experimental"? Also, as others have said, P31 and P279 do have clear definitions - they are based on W3C standards, and there is now some good documentation for them (including "part of") by User:Stevenliuyi. Silver hr (talk) 23:10, 30 March 2013 (UTC)

Oppose Use only one property for all "instance of" will create confusion: it is as "put together different things like potatoes and shoes".
1. If, for example, I want make a query for the building built in 1932 in Germany, I need to know three property: for buildings, for years, for countries. So the advantage to have only one property for "instance of" imho is marginal.
2. It is very difficult with only one generic property establish what item is "instance of" another item: for example Andromeda Galaxy instance of geographical features, galaxy, or spiral galaxy? Mont Blanc instance of geographical features, mountain, Graian Alps or Mont Blanc massif?
3. I propose to use this property as conjunction between P107 (that imho is useless to delete because the infobox task force is yet separated following P107 categorization) and the "instance of" properties listed above. We need something to distinguish for example all the items with main type (GND) = geographical feature in countries, cities, roads, rivers, mountains, lakes, and so on. P31 and P279 can be very useful for this. --Paperoastro (talk) 15:32, 30 March 2013 (UTC)

It seems that we need better documentation of "instance of".

The Mont Blanc is not an instance of the Mont Blanc massif, it is a part of it.

We should use the most precise "instance of" available. Andromeda is an instance of spiral galaxy. As spiral galaxy is a subclass of galaxy, it can be automatically inferred that it is also a galaxy, and so on. That is not something we can do with "type of".

The instance / subclass couple does make query much easier. If you want to restrict your search of German buildings to religious edifices, you can easily do that with instance/subclass. If you want to use "type of", you would also need a "type of religious edifice" property. That is virtually endless. --Zolo (talk) 18:53, 30 March 2013 (UTC)

Comment User:Stevenliuyi put together some really great documentation for 'instance of', 'subclass of' and 'part of': User:Stevenliuyi/Differences_among_basic_membership_properties. Emw (talk) 18:59, 30 March 2013 (UTC)

Support Silver hr (talk) 23:10, 30 March 2013 (UTC)

Oppose. I hear this argument several times and I don't agree. See my discussion with user Emw on his user talk page. But I seems impossible to create on "type of" properties for each type of different infobox in all Wikipedias - why? I see not a single problem doing so. But I see many problem to lump all together. To retrieve the right value out of multiple P31/P279, THIS I would say is impossible. And even not, it would complicate queries and infobox usage extremely. Last but not least: How should Wikidata Phase III work without specific properties? E.g. automatic creation of a list of all 'watercraft types', without having this property? --Nightwish62 (talk) 22:12, 31 March 2013 (UTC)

What do infobox names represent? They represent the names of classes, which is what 'instance of' or 'subclass of' exist to do. What do "type of" properties represent? They also represent the names of classes, just derived classes; 'subclass of' exists to fill this need. "Type of" infobox parameters are an adaptation -- a kludge -- to enable support for specifying the value of one level of subclass. The P31 and P279 properties are transitive, so e.g. if "A subclass of B" and "B subclass of C", then "A subclass of C". Thus they allow handling an arbitrary depth of subclasses, from saying that a boat is a subclass of watercraft to watercraft is a subclass of vehicle all the way up to physical object is a subclass of entity. They are based on the rdf:type and rdfs:subClassOf properties from relevant W3C recommendations. The ability to make simple entailments like "A subclass of C" with these properties to retrieve the right value out of multiple 'instance of' and 'subclass of' (read: rdf:type and rdfs:subClassOf) statements is a core feature of querying in the Semantic Web. It is a routine operation in Semantic Web querying and not at all impossible. To create a list of all watercraft types, one would simply select all items that satisfy the claim 'subclass of watercraft'. Emw (talk) 04:40, 1 April 2013 (UTC)

Comment I really ask me what's the development team opinion about this. They gave us a tool and we've to find out how to deal with it? Was there really no plan/guidelines/suggestions from the development team? Perhaps we should ask what's their idea it should work? --Nightwish62 (talk) 22:28, 31 March 2013 (UTC)

The development team as a whole does not want deal directly the actual content, but individual members of the team may be willing to give their opinion if you ask them. --Zolo (talk) 05:28, 1 April 2013 (UTC)

Not done, no consensus to delete after a week of discussion.--Jasper Deng (talk) 06:18, 5 April 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:P107

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. P107 (P107): (delete | history | links | entity usage | logs | discussion) There has already been lengthy discussion about this property (see its talk page) and it is time to take a decision. I'll try to sum up (of course I am biased, but I hope I get the acts corectly).

Some users (like me) supported this property as a kind of ready-made high-level classification. However, because of quirks in the GND system, and because of our particular Wikipedia-related needs, it does not work well at all. For instance, families are classified as "person", or Wikipedia category pages are not part of the system.
Currently, this property currently uses items like person, but it is wrong: GND do not define person exactly the same way as usual person, and should thus use of separate item. There seems to be consensus on that. That means bots have to do a massive cleanup, and so the current wide use of this property should have have too much weight in the decision.
Currently, the main use of the property in to classify people as "person". THe instance of property can do that as well.
If there the GND classification scheme is useful, we can use it in full. There is no need to restrict to "main types". That would be a 3-letter string. The first one defines the "main type". That means that we could easily move all current P107 to the new property without any loss of information. The new system would make it clearer that the GND type is a controlled vocabulary with its own way of doing things, and that we should not always rely on common word usage there. --Zolo (talk) 16:41, 28 March 2013 (UTC)

Delete completely. We can and should use "instance of" or "subclass of" as necessary to define an item, and for actual items defined by the GND, switch to use the claim GND identifier. There's no reason to document their database on top of ours. While the property was probably a good one for the purposes of "getting our feet under us", I think its use has passed. (On top of which, there are far too many wasted bytes on discussion related to the property.) --Izno (talk) 18:47, 28 March 2013 (UTC)
I think it's good to have a property that allows some basic sorting for all items. I don't actually care if this is GND or not. With anything basic, eventually you will have items that aren't easy to comprehend and might not matter that much as they are better sorted through other properties. -- Docu at 21:30, 28 March 2013 (UTC)
On that point, I'm not sure whether I agree or disagree. From one point of view, everything via subclass of or instance of will be traceable to that "basic sorting". A second point of view, closely aligned with the first, is that it shows no real relationship. Something is a "term"; great! That... doesn't actually tell me what it is. From an opposing point of view, something like WD:List of properties might be chaotic instead. Just musing; I guess I more disagree in that no, not everything needs that "basic" element of organization. --Izno (talk) 21:44, 28 March 2013 (UTC)

Certainly though, I think you'd agree that P107 doesn't do the job it needs to do, and is certainly more of a job than it needs to do. --Izno (talk) 21:50, 28 March 2013 (UTC)
I think it does. It already allows consistent identification of "persons" which are sorted into male/female/etc. That you could build multi-parameter queries that eventually might achieve the same seems very ambitious and not likely to happen soon. Even "term" helps as it tells you that an item is not about a person .. -- Docu at 05:02, 29 March 2013 (UTC)

One of the main problems with P107 is that it actually does not allow consistent identification of "persons". If you see a P107 value (i.e. GND main type) of "person", the item could be a person, or it could be a family, god, literary or legendary character, pseudonym, collective pseudonym or a spirit. All of those items that are clearly not persons are captured by the P107 value "person". Emw (talk) 23:06, 29 March 2013 (UTC)

Oppose P107 is the most popular property: Used nearly 1 million times (Wikidata:Database reports/Popular properties). It has a clear function and a defined vocabulary (Template:Entities). It is used by authority templates in Wikipedia and Wikimedia Commons. (BTW: Two weeks ago I've started a discussion if P107 should have separate ~~properties~~ items, see here.) --Kolja21 (talk) 23:36, 28 March 2013 (UTC)
Oppose This is an important property for its use in Authority control. It might have been overused into sections where it's not relevant, but at least in the Typ = P, case it's extremely useful. I have already created a bot proposal, with a lot of support to import lots of Authority control data, including P107, Wikidata:Requests for permissions/Bot/VIAFbot. It's close to completion, and will make P107 seem less lonely at the only current Authority control property [2] as it adds, VIAF, LCCN, BNF, and ISNI data along side of it. We don't have to use GND where it doesn't make sense, and I don't think that every wikidata item should have a GND property, but it is relevant and appropriate for a lot of pages. Maximilianklein (talk) 00:27, 29 March 2013 (UTC)
None of which needs this claim to exist. The GND identification number is more than enough for this task. Anything else we can use for our own, homegrown categorization scheme. From where I sit, that revolves around instance of/subclass of. --Izno (talk) 01:30, 29 March 2013 (UTC)

I'm going to agree with Izno here. The rationale seems to be comparing apples and oranges: the existing authority control properties are all simply authority identifiers; this property is not an authority identifier. The function details at Wikidata:Requests_for_permissions/Bot/VIAFbot make no mention of this property:

"Find transclusions of the Deutsche Template Vorlage:Normdaten and English Template Template:Authority control, search for the VIAF template parameter, and if there's no disagreement, write the Property:VIAF (approved, waiting for StringValue) to the Wikidata item, following the enwiki Wikidata interlanguage link. If consensus allows, there's possibility to also Populate the Property:ISNI (approved, waiting for StringValue simulataenously as for ~90% of ISNIs, there is a one-to-one correspondence."

And File:Wikidata VIAFbot Flow.png makes no mention of this property. Did the folks who supported the approval of VIAFbot know they were supporting this feature? Emw (talk) 02:47, 29 March 2013 (UTC)
Support P107 has several major problems that make it an apt candidate for deletion, or at least strong deprecation. With this property:
1. Any item that is not a person, place, event, organization or work is classified as a "term", which conveys no information. We need to be able to classify things like gravity, carbon, DNA, cancer, clarinet, Twelver Shia Islam, fashion boot, dog and potato as more than simply "terms". One sixth of this property is kruft.
2. The nature of P107 implies that the property is only for the highest level of classification, and that additional properties would be needed for each level in the hierarchy of classification for lower-level types. This would entail lots of unnecessary work to create and update classifications. For example, want to specifically classify Nauru? If this property persists, then you'll need to add something to the effect of "main type: Place" and "subtype: Administrative unit". The problem gets drastically worse for subjects with more levels of classification, like organisms, instruments, molecules, diseases, towns, etc.
3. Families, gods, literary or legendary characters, pseudonyms, collective pseudonyms and spirits are called persons. The standard response to this glaring problem is "'person' is meant to generalize, don't take the term literally". That is not a sufficient solution. Really, the GND main type "person" means "any instance of an anthropomorphic thing, or a pen name, or a group of such instances." This stretches the definition of "person" well beyond recognition, which will perennially confuse Wikidata users (and rightly so).
4. Not even the GND directly uses GND main types. GND main types (or "high level entities") are treated as internal details, and hidden from both human and machine users in favor of more specific types. For example, the "type" (German: 'Typ') parameter for the GND entry on Nauru has the values gik (territorial corporate body or administrative unit) and gil (country) -- these classes are both derived from (i.e. more specific than) the GND main type g (place or geographic name). If the GND thought GND main types made sense to apply to items, then you would expect to see 'Nauru' with a "type" of "g" (place or geographic name) -- but that's not the case.
I would invite anyone who opposes the deletion of this property to address these issues point by point, specifically. Feel free to leave comments immediately below the relevant point above, or however works best. Emw (talk) 02:24, 29 March 2013 (UTC)
Well, your fight against this property is legendary, but I can't see any new arguments. Just take for example topic 4: "Not even the GND directly uses GND main types." One click proves that this statement is false: GND 132522136 Barack Obama, Type "Person". GND 101375069 Peter Gast, Type "Name" (= disambiguation). --Kolja21 (talk) 02:38, 29 March 2013 (UTC)
Your point about the GND entry for Barack Obama is a facsimile of one I rebutted in a discussion several weeks ago. To reiterate: the 'Typ' parameter value used in that entry is not "p", it is "piz". The non-main type "piz" is equivalent to the main type "p", which means a class's status as a GND main type is an internal detail that the GND ontology intentionally obscures. The Barack Obama entry is an example of the GND hiding the fact that "person" is a main type; it is using "person" in the same exact way it uses the dozens of other classes listed in the 'Classes Overview' section at the top of http://d-nb.info/standards/elementset/gnd. This indicates that the GND senses that the GND main types are not appropriate to use as they are with P107. Emw (talk) 03:23, 29 March 2013 (UTC)
Oppose five of the six main types are a help. It is only "term" that doesn´t work. For example, we may have a million items of animals and plants and therefore we should increase the number of "main types". --Goldzahn (talk) 07:39, 29 March 2013 (UTC)
Comment We could add a type for species if we want to import Wikispecies but then we would have a general discussion why we create this type and not others. In the end we would have an unfinished classification system that is redundant to other generic properties. --Kolja21 (talk) 12:38, 29 March 2013 (UTC)

In the end Wikipedia/Wikidata is no library. There are no books about single species or stars and therefore libraries stick them all in one basket called term. By the way, "event" is difficult too, because "historic events" are no events, but "term". A sports event from 1930 is a "term" and one from 2010 an "event"? That is strange. --Goldzahn (talk) 13:14, 29 March 2013 (UTC) Maybe "event" is a new main type and they didn´t want to relabel their old books. Manpower is always short in libraries. --Goldzahn (talk) 05:52, 31 March 2013 (UTC)

I would also tend to think that it could be useful to have a very general property that would help sort out items in a very general way. But as you point out, we would need more types, and also, I think, redefining some GND types. That would not be the GND main type anymore, rather a different property. --Zolo (talk) 20:39, 29 March 2013 (UTC)

Oppose Maybe I don't understand all critics correctly, but I see no harm in leave this property be. Wikidata will probably use the richest set of identifiers for its entities, and this will both make Wikidata (and Wikipedias) richer and libraries aware of quirks, errors, and overlappings. They would be able to compare use of their IDs and maybe correct their system. Having us (wiki*dians) to help them is one of the best feature I can think of Wikidata, because of course this feedback to us again. We can put some stricter rules in the use of this property, but delete it seems to me overkill. Identifiers are not panacea, they are tools written by librarians in different contexts for slightly different purposes. Still, they are useful to integrate different cataloging systems. Aubrey (talk) 07:52, 29 March 2013 (UTC)
Comment, then I think you agree with my proposal: use the full GND system in a string property, instead of just the "main type" in an item property. --Zolo (talk) 08:03, 29 March 2013 (UTC)
To change this property form "main type" into a kind of GND-RDF-Schema has been proposed by Emw on 26 February 2013 (see Property talk:P107). I don't want to repeat the whole discussion but if you take a look at Entitätencodierung: Vergaberichtlinien (German) you will see that three letter code types like "wie" (use still unclear) or "sip" (products and brand names except type "siw") are no help for Wikidata. It would reverse the intentions of a basic property easy to use. --Kolja21 (talk) 12:25, 29 March 2013 (UTC)
If I understand Aubrey correctly, his point is that this property would help make the GND system better. For that, it would make sense to use the full GND system here, not just the main type. --Zolo (talk) 14:43, 29 March 2013 (UTC)
Oppose It´s usefull and a important system.--Norbert Bangert (talk) 09:35, 29 March 2013 (UTC)
Support: several conceptual problems as explained by Emw, and "instance of" or "subclass of" are much more accurate. --Gloumouth1 (talk) 10:21, 29 March 2013 (UTC)
Comment the problem with calling it a "useful" or "important" is that "instance of" and "subclass of" can do the exact same things as this property. Where this property is used, one of those can say the exact same things, and that's without being tied to a system which is certainly flawed by its definitions (as explained by Emw). More importantly, we don't need to replicate an external database here by adding types and using types which duplicate that database's types. It is useful enough only to use the GND identification value, because a) that restricts it to those items which even have a GND type to begin with, and reduces the work we have in maintaining this site. Every single type we end up adding to the system ends up in some amount of work for us. This type has little benefit and several illustrated problems associated with it. I'm still not seeing arguments against those points. Eliminating the property forces people to associate Wikidata's database with the GND's database only where it is possible to associate it. --Izno (talk) 12:53, 29 March 2013 (UTC)
Oppose per Maximilianklein & Kolja21. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:07, 29 March 2013 (UTC)
Oppose I love this property. It turns Wikidata into an international database. If you want to see the difference to "instance of" just turn your language code into ja or ru. --ThorstenX1 (talk) 13:22, 29 March 2013 (UTC)
Comment If the only thing internationalized we had to offer was "person" or "event", it would seem kind of pointless to me. Luckily many other things are already translated, and things should progress pretty fast. --Zolo (talk) 14:43, 29 March 2013 (UTC)

That's an odd reason to oppose this, because it's not a problem with this type but a problem with this being a wiki. (One of the problems being that this wiki does not have fallback languages installed, when it really should.) The deprecation of this property could (should) include a transfer of all of the claims where GND type is used and which are not already defined by instance of/subclass of into instance of/subclass of, as appropriate. --Izno (talk) 16:38, 29 March 2013 (UTC)
Support.In present form (strictly 6 counter-intuitive values derived from one of the hundreds librarian systems) it is much less useful than "homegrown categorization scheme" (c) Izno. But due to some (accidental or not) reasons P:107 was accepted as a "main type" which distracted community powers from truly useful things. Another possible solution is to mark out this property from all rules, clean up from the items not mentioned at official site and switch values to String value. Infovarius (talk) 18:17, 29 March 2013 (UTC)
Oppose Even though this item may be vague (esp. with regards to "term"), I can still think of several very useful applications of it. Since it's a system with a limited number of options, it makes it much easier to use this to weed out incorrect uses of other properties. Say item A with main type=person claims married to item B with main type=place. Then you can safely say that either item A has an incorrect claim, or item B has an incorrect main type. In either case it is something you can find out and fix easily (with the right tools). You simply can't do anything like that easily with instance of, since it's an open system with endless possible values for items. And, yes, this main property is by no means perfect or even useful for Wikipedia articles, but as a maintenance tool it can be immensely useful. Jon Harald Søby (talk) 12:43, 30 March 2013 (UTC)

CommentI will build something like this in my tool. For example, the value of the designer-property should be a person or an organisation. And, we could build vandal-bots, that scan new statements in this way. --Goldzahn (talk) 18:14, 30 March 2013 (UTC)

Comment Jon, that's an interesting argument, but I think it's incorrect on two fronts. The central assertion seems to be that GND main type (P279) would make it much easier to weed out incorrect statements with the right tools, and that it would not be easy to do so with instance of (P31). This argument would assert, for example, that it would not be easy to say that a statement like "item A with instance of=person claims married to item B with instance of=monument" is invalid. In fact, this sort of evaluation -- which would use simple entailment with P31 -- is a core feature of querying in the Semantic Web.

Since P31 is mapped to rdf:type, queries can "walk up the chain" of hierarchy to get all instances of a certain class. So, the rough SPARQL queries to get all items with such a statement with P279 and P31 would be very similar.

With 'GND main type' (P279):


SELECT ?item_a 'married to' ?item_b
WHERE  {
?item_a 'GND main type' 'person' .
MINUS { ?item_b 'GND main type' 'person' }
}

With 'instance of' (P31):


SELECT ?item_a 'married to' ?item_b
WHERE  {
?item_a 'instance of' 'person' .
MINUS { ?item_b 'instance of' 'person' }
}

The difference is that with P31, you could say that item_a 'instance of' monument (and monument 'subclass of' place) and item_b 'instance of' person -- whereas with P279, you can only say 'Eiffel Tower' GND main type 'place' and 'Tony Blair' GND main type 'person'.

Also, I would dispute the more basic idea that a 'married by' claim (or any claim restricted to persons) is valid if both subjects have GND main type 'person', because as mentioned in my original list of arguments against this property, the GND main type person includes families, gods, literary characters, pseudonyms, collective pseudonyms and spirits. Is a claim that a person is married to a literary character valid, or that family is married to a family? Emw (talk) 18:52, 30 March 2013 (UTC)

Comment @Emw: If you want to improve the use of this property, it would be easy to create separate items, since you know this threat: Wikidata talk:Notability#Main types (GND). --Kolja21 (talk) 01:26, 31 March 2013 (UTC)

Sorry, I don't see how that relates to the points above. Are you proposing to change P107 from its current basis on the GND main types as defined in the GND Ontology to some (more reasonable) basis on custom-defined "main" types? If so, then I think that warrants considerably wider discussion.

If not, then I think the major problems with this property's definition of "person" persist. Those problems include things like invalidating Jon Harald Søby's rationale for opposing this property's deletion, and the simple absurdity of considering families and literary figures to be persons.

(Also, when you say "threat", do you mean "threat" or "thread"? They are very different. "Threat" is rather accusatory and "thread" is totally normal. Until your comment just above I thought your consistent usage of the word "threat" towards me over the past week or two was intended to have the word's actual meaning, but now I suspect that you very well might mean "thread".) Emw (talk) 04:26, 31 March 2013 (UTC)

A proposal: Since de:WP has several hundred thousands of GNDs a solution could be to create additional main types for Wikidata and the template in de:WP knows that the new main types will be translated to one of the GND-types. For example, there could be a new main-type called "non-person" which will be translated to "person" or "astronomical object" that will be translated to "geographical feature". --Goldzahn (talk) 10:03, 31 March 2013 (UTC)

Are you suggesting using GND identifier (P227) instead of P107? This seems to be in line with Izno's comment below. If so, what would be done with this property? I think using GND identifier would be better than using GND main type, and I think it's an another argument to deprecate and then delete this property. Emw (talk) 20:26, 31 March 2013 (UTC)

P227 is a string-property. It is not usable as a main-type property. --Goldzahn (talk) 20:49, 31 March 2013 (UTC)

You are right. I will change my tool in such a way, that the user has the option to choose between GND-type and "instance of". You could ask "User:Magnus Manske", since he is the original author of my tool to change his tool too. You should know, that a lot of people are using his tool. --Goldzahn (talk) 06:19, 31 March 2013 (UTC)

Oppose We need anyway some kind of classification independently of the classifications made by Wikipedias. At now we have main type (GND). If we will remove it, we will need to make another kind of classification. As explained above, I propose to use this property in conjunction with P:P31 and P:P279 to improve the classification. In fact we need something to distinguish for example all the items with main type (GND) = geographical feature in countries, cities, roads, rivers, mountains, lakes, and so on. P31 and P279 can be very useful for this. --Paperoastro (talk) 16:00, 30 March 2013 (UTC)

Support This property is inseparably tied to a particular ontology (GND), created by German librarians for library-related purposes. Wikidata is not a German library, nor is it a library at all. It is a general semantic database supposed to be useful to anyone in the world, just like Wikipedia. From what I've seen in multiple places, this property is officially endorsed on Wikidata to be used on all items to classify them. However, due to this property being tied to the GND ontology, this unavoidably and effectively means Wikidata officially uses and endorses the GND ontology. Where is the community consensus that Wikidata should officially adopt the worldview of German librarians? As to specific points:

Popularity is irrelevant. If something is inferior, it should be improved, no matter how popular it is in its existing state.
We can classify every item on Wikidata without this property by using the properties instance of and subclass of, and we can do it much better. See above for explanations of how this property defines things that are not persons as persons, and how it classifies a large majority of things as "terms", which is just a synonym for "thing that's not in any other class"--and those are likely not the only problems. This is not good. As for instance of and subclass of, they are based on W3C-standard rdf:type and rdfs:subClassOf, making them compatible with the rest of the Semantic Web.
This property is not used for authority control, P227 (GND identifier) is.

Silver hr (talk) 01:25, 31 March 2013 (UTC)

@no 3: P107 is used by authority templates in Wikipedia and Wikimedia Commons as "parameter: TYP". Entering "wife", "lady", "girl", "woman", "female" etc. in P31 can not be used by these templates. --Kolja21 (talk) 01:35, 31 March 2013 (UTC)

I see no reason why this property should be inseparably tied to a particular ontology. Actually I would never use the <main type> 'person' (I don´t call it GND-type) for fictional persons. They are <instance of> 'character (fictional)' (Q95074) and <main-type> 'work'. I don´t care what people write in pdf-files. In Wikipedia I use wikilinks to foreign Wikipedias in the text, although they get deleted soon. Sometimes rules are wrong. --Goldzahn (talk) 06:19, 31 March 2013 (UTC)

@Kolja21. Commons does not use the GND type. The only “type” I see there is in commons:Template:Creator. As it happens, it was introduced precisely to do what the GND main type does not: distinguish clearly between people and groups of people. Is there any real use of the GND type in de.wikipedia ? It is not displayed in articles. I do not consider de:Vorlage:NORMDATENCOUNT as real use. It is a maintenance tool, and we could easily have similar things without this property. –Zolo (talk) 08:42, 31 March 2013 (UTC)

@Goldzahn. The current property is called “GND main type” and the name was chosen to make it clear that it should comply with the GND’s classification system. If you do not want to comply with them, I do not see why you want to keep this property. --Zolo (talk) 08:42, 31 March 2013 (UTC)

Because there are a million of them and we need main types (at least, I will use them together with <instance of> and <subclass of> in my tool). We have refocused other properties, why not this one too? Task force infoboxes has to find a solution which serves its use in de:Wikipedia and its use as a maintenance help in Wikidata. Maybe, in the long run, <instance of>, <subclass of> and <part of> will take its role. But, I don´t know if people do understand those three properties. I´m sure there are lots of wrong uses (Is it possible to write a maintenance bot that correct maintenance properties? Maybe if there are two maintenance systems?). <Main type> could be an easier solution, if its problems are solved. If not, people will use parts of <main type> and the three other properties together. At least, that is what I´m doing. By the way, someone should write such a maintenance bot and the experience will tell us what to do. At the moment it is just theory. --Goldzahn (talk) 10:53, 31 March 2013 (UTC)

That seems to make sense. I also tend to think that a very general property can be useful, and (whatever the solution who choose), provided we have just one of them, I do not think it can have much negative impact (I am much more worried about the "type of" properties of the above request). However, what you are suggesting is to change the meaning of the property, and it would not be the GND main type anymore. In that case, I really think you should make a more formal proposal to change the label and the possible values of this property. --Zolo (talk) 16:38, 31 March 2013 (UTC)
Goldzahn, this property is tied to a particular ontology because that was the result of a vote on the Vote for the nature of this property section of the P107 talk page. The nature of P107 has been voted on and established: P107 is based on the GND ontology, and confined to the GND main types person, place, organization, event, creative work, and term. This discussion is about the deletion of such a property. From what you've said, it sounds like you don't support P107. Emw (talk) 16:47, 31 March 2013 (UTC)

Are you speaking of those three pro votes? If someone finds a better solution, I guess, there will be more than three pro votes. Maybe we should say, that we discourage (is that an English word?) the use of the <main type>-property for certain topics. Instead <instance of> and <subclass of> should be used in those areas. And there is something else. 'x' <is instance of> 'river' <is subclass of> 'watercourse' <is subclass of> 'body of water' <is subclass of> 'geographical feature'. That means, the <main type> is part of the <instance of> hierarchy. Another example: 'Toyota WISH' <is subclass of> 'automobile', but if you look further into this tree of class, it is getting strange. 'vehicle' is a <subclass of> 'machine', which is an <instance of> 'tool' and between you will find lots of <main types> 'term'. It seems, that <instance of>/<subclass of> is no hierarchy, but a net, similar to some categories in Wikipedia. I´m not active in this topic in Wikipedia, but I know that people do work hard in de:WP to move the category-system away from a net. On the contrary the GND-type, which we use only parts of, is a hierarchy. I don´t know how useful <instance of> and <subclass of> really are for maintenance work. Maybe less than I thought. And it seems, that the <main type> are just certain points in a net of class-relations. The question is, what value do these points have? It seems, that they are different for each main type. --Goldzahn (talk) 20:40, 31 March 2013 (UTC)

How are the examples you cited strange? The 'instance of' and 'subclass of' properties form a hierarchy known as a rooted directed acyclic graph (DAG). The root of the hierarchy is entity, which is the same as in established upper ontologies like SUMO, and assumed in widely used languages like OWL and CycL. I'm not familiar with category curation on German Wikipedia, but I imagine their efforts to move the category system away from being a net are significantly focused on removing cycles. The 'instance of' and 'subclass of' properties do not permit cycles; if one exists, then it's an error. I don't think having a property specifically for certain "main types" makes sense. It doesn't befit a project that aims to structure all knowledge. Emw (talk) 01:11, 1 April 2013 (UTC)

The thing I still don't get is why Property:P227 does not satisfy whatever need P107 is supposed to fix. P227 is scoped to real uses of the GND library and allows us to classify things as we wish. If we want, we can have a "high level" classification system, but whatever we do, P107 simply cannot fill that high level need (if it really exists; I don't think it does) satisfactorily. --Izno (talk) 18:03, 31 March 2013 (UTC)

P227 is only a number (= GND identifier). If you look at the authority temples they have different identifiers (like GND, LCCN, VIAF etc.) plus the main type. We work with the Parameter TYP successfully since a year. For example: Type n tells use that disambiguation and persons are mixed; Type p without P227 that a GND is missing. Since 2005 we have a list to apply for a GND, type p (former PND) etc. Have you ever tried Wikipedia-Personensuche? It's a great tool also based on P107. (It does not need a GND.) --Kolja21 (talk) 03:21, 1 April 2013 (UTC)

Comment, it seems that the most useful GND type is "person", and it is by far the most widely used in German Wikipedia. I think all person items should have their "instance of" property set to "person". That means we would get the same result, without even needing inference, except that we would not have to adopt the GND's definition of person. --Zolo (talk) 05:35, 1 April 2013 (UTC)

I´ve proposed to split <main type: person>. Maybe a better solution would be to turn <main type: person> into a virtual type. That means, each person is <instance of> 'person' and only the item 'person' is <main type: person>. The same would be for the items <fictional character>, <music band>, <ghost>, ... Because bots would have a problem to move each item into the right class, we would have in practice a hybrid property. This could be a solution if it is possible to write a template that can handle such a hybrid property. And we would need a way to lock this statement, similar to some articles in Wikipedia. If a test shows that this is possible, we should write a WD:RFC --Goldzahn (talk) 06:44, 2 April 2013 (UTC)

Goldzahn, this proposal seems reasonable. It's been proposed before, e.g. as part of the discussion at Property_talk:P107#type. This would effectively be the "GND but not only main types" option in Property_talk:P107#Vote_for_the_nature_of_this_property. The overwhelming majority of participants in this discussion don't seem to dispute that having a property for only GND main types is a bad idea. But that's what P107 is, and thus it's a bad idea. P107 is a property where "person" includes families, gods, literary characters, pseudonyms, collective pseudonyms and spirits. Why do we need the GND ontology -- main types or both main and non-main types -- to say something like 'Barack Obama instance of person'? Emw (talk) 00:42, 4 April 2013 (UTC)

Comment that has historical reasons. GND, type p is the former en:Name Authority File (PND) and is used in Wikipedia since 2005. --Kolja21 (talk) 13:24, 1 April 2013 (UTC)

Oppose an ontology of all is impossible so we'll always have properties that are very useful in one domain and completely useless in another one. We'll just end up with multiple overlapping systems that coexist. Multichill (talk) 08:52, 1 April 2013 (UTC)

Multichill, could you please clarify how that's a rationale for opposing the deletion of this property? I don't know if I agree with your statement, but in either case it seems orthogonal to the discussion of whether this property should be deleted. Emw (talk) 23:25, 2 April 2013 (UTC)

Support For the reasons I've given on the talk page, and explained perfectly well by Emw. Trying to coerce the world into seven broad categories is a recipe for utter failure. Wikidata is too important to tie it inextricably to the GND. "Ah, but it's used by German Wikipedia". So? Based on the use I've seen for it so far, it's being used badly. Anything which doesn't fall within the remit of the "main types" is being flung into "term". Python is not a "term", it's a programming language. The use of term as a general catch-all category for things that don't fit into the other categories means that we are failing to draw out the use-mention distinction. Python isn't a term, it's a programming language. When I use the word 'Python' to refer to the programming language, it is a term. Terms have properties that are distinct from things. We can say 'Python' is six characters, but Python is not six characters because it isn't a term, it's a programming language. It has properties like compiled or interpreted, type system etc. P107 fails to draw that important distinction. Any statistics that one derives from it are essentially useless. German Wikipedia says "oh, we use it to work out how many people there are?" Okay. But given that the "person" type includes things that aren't people like families, that information is basically wrong. Deriving uninteresting statistics from incorrect data because of a strange desire to fit the world into seven boxes? Yeah, no. Stop that silliness now. —Tom Morris (talk) 16:34, 1 April 2013 (UTC)

Citing Template:Entities (GND main types): The terms "person", "place" etc. are meant to generalize. Please don't take them literally. P107 allows quality control, not only in Wikipedia but also in Wikidata. Just take a look at User:Sk!dbot/conflict. The list helps for example to prevent vandalism. --Kolja21 (talk) 19:07, 1 April 2013 (UTC)

That's rare case. The list is not about vandalism, but about misunderstanding of the property in discussion. Worshipping this property is already used for losing information. Infovarius (talk) 17:56, 2 April 2013 (UTC)
"Citing Template:Entities (GND main types): The terms "person", "place" etc. are meant to generalize. Please don't take them literally." Kolja21

This is precisely the standard reply I referred to in my original description of the major flaws in this property. When someone notes the glaring problem that families are not persons, they're told the above. This is simply not an adequate solution to that problem. The comment from Jon Harald Søby above is an excellent example of why: contributors and tool developers assume that "person" does not mean "family" (or "literary figure", etc.), and then assume we can use it to validate properties like "married to". As explained above, the fact that the GND main type "person" means things that are clearly outside the definition of "person" means that this property's potential role in claim validation is drastically less than it seems at a glance. This basic, significant problem, as well as the others noted in my original description, have not been resolved. Emw (talk) 00:14, 3 April 2013 (UTC)

Oppose With Wikidata:List of policies and guidelines there currently are no policies / guidelines regarding (partial) redundancy of properties. The flaws of GND typology range from "minor" to "severe" depending on intended use / the viewpoint one has. There are other schemes which don't force one to "fit the world into seven boxes" – But are these valid reasons that justify deletion of P107? No: GND main type can be used in productive ways and I can't see how it hurts, or could potentially hurt Wikidata progress. -- Make (talk) 21:10, 2 April 2013 (UTC)

Major flaws in this property are enumerated in my original post in this discussion, here. They have not been addressed. It would help if the supporters of this property would specifically comment on those concerns, and engage in follow-up discussion about them. Emw (talk) 23:44, 2 April 2013 (UTC)

“We'll just end up with multiple overlapping systems that coexist.“ Multichill (above) – Makes sense to me. The flaws of GND high-level classification are well documented at this point and they won't go away. See Wikidata_talk:Notability#Main_types_(GND) for a solution on how to make P107 consistent: “ Imho we need seperate items for the GND main types. This also would help to distinguish between properties that use "controlled vocabulary" (P107: GND main types) and those who use "uncontrolled vocabularies" (P279: generalization and P31: is a)” Kolja21. – This RfD asssumes that there should be "one main ontology" for Wikidata items. But that is not consensus (and won't work in my opinion). -- Make (talk) 14:56, 3 April 2013 (UTC)

How does this RfD assume there should be one main ontology for Wikidata items? Deleting this property would not mean getting rid of the GND ontology, nor would it imply some rigid ontological monoculture. (Where is this notion coming from?) As I imply in point 4 in my original description, using the GND types like the actual GND does -- by classifying items with the most specific GND type/class available -- would be much better than the GND-main-type-only approach P107 uses. But I don't consider this nomination to be about changing the nature of P107, since that has been established. To me and I think many others, this discussion assumes that P107's nature has been established, and is about whether such a property should exist.

This is a peculiar situation. Noone seems to be seriously disputing that there are major flaws with this property -- as evidenced by the lack of engaged discussion about the major flaws outlined in my original description -- yet many support it. If this property really isn't so bad, then why not rebut those specific points? Emw (talk) 00:19, 4 April 2013 (UTC)

You've started multiple threats about P107 and have received in the last two months dozens of answers to your questions, also the questions mentioned above. On the other hand I don't see any answer of you on Wikidata_talk:Notability#Main_types_(GND). I still think (thanx to Make to bring it you again) that separate items for the GND tpyes would help your idea to establish a classification system without controlled vocabulary. (For example: P107 would have the item "Typ p, person" and P31 values like "single person", "family" or "literary figure".) --Kolja21 (talk) 16:59, 4 April 2013 (UTC)

Kolja, do you read my replies to you? I've made several in this discussion, but you don't follow-up, and seem to ignore them. For example, I asked you a few days ago in this thread: "when you say 'threat', do you mean 'threat' or 'thread'? They are very different." No reply. That reply had other, more on-topic points that related specifically to the P107-specific comments you made -- those got no reply from you either. The re-rebuttal of your point about 'person' (see "Your point about the GND entry for Barack Obama is a facsimile of one I rebutted" above) also got no response.

These replies of yours are not answers, they are drive-by comments. The replies go one level deep, rehashing arguments that have been rebutted, and then aren't followed up on when they're rebutted yet again. They're also peppered liberally with ad-hominem comments about how I "open a new threat (sic?) every other day", which avoids engaging in discussion about the actual issue. This pattern has played out here (no reply to "I'll speak to each concern in order"), here (no reply to "Why shouldn't the authority templates be changed...?"), here (no reply to "If an item has a value of person, place, organization or event for P107, then would it not be valid to apply the same value on that item for P31?") and here (no reply to "Are you opposing this proposal? If so, how does what you wrote relate?"). Your recent replies seem to assume that exacerbated expressions about the regularity of complaints about this property are somehow an adequate answer to those complaints, and that I am the only person raising these issues. They aren't, and I'm not.

With that meta-commentary out of the way, I'll reply to the substantive part of your response. If I understand it correctly, you suggest that creating separate values for GND non-main types and specifying them with P31 would help solve the major flaws of this GND-main-type-only property. I disagree. Even if that proposal were put into effect, it still seems like P107 would A) still classify most of human knowledge as merely a "term", B) persist the bad idea of having multiple properties for multiple different levels of classification, C) still conflate "person" and "family" and "literary figure" etc., and D) still not use GND types as they're used by the actual GND. Is that incorrect? If so, how? Emw (talk) 04:12, 5 April 2013 (UTC)

Not done, no consensus to delete after a week of discussion.--Jasper Deng (talk) 06:14, 5 April 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:P266

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 am closing this as delete due to the clear consensus. However, it needs to be unlinked before deletion. --Rs chen 7754 06:34, 13 April 2013 (UTC)

P266 (P266): (delete | history | links | entity usage | logs) Isn't such features should be implemented with queries? Additionally list could be too long for certain cemeteries (example: w:ru:Список похороненных на Новодевичьем кладбище). --EugeneZelenko (talk) 03:29, 13 March 2013 (UTC)

The advantage of this is that you can start building them from both sides.

This as with several other reciprocal properties. -- Docu at 19:49, 13 March 2013 (UTC)

we should wait for bidirectional properties and decide later--Svebert (talk) 11:33, 16 March 2013 (UTC)

it should be deleted, as per EugeneZelenko. --Ricordi samoa 00:13, 26 March 2013 (UTC)

I don't think "could be too long" is something we should be worrying about. I think it works fine e.g. on Q8086145 and many churches. -- Docu at 21:37, 28 March 2013 (UTC)

I agree with EugeneZelenko on this. Q8086145 may work fine, but don't try to add all of pl:Kategoria:Pochowani na Cmentarzu Powązkowskim w Warszawie into Q168886 ! It is true, that it would sometimes be faster to add statements in the cemetery's item, rather than in the people's, but if the list is very long, a bot can probably help. --Zolo (talk) 22:28, 28 March 2013 (UTC)

Q168886 is not really planned, but why not? -- Docu at 04:48, 29 March 2013 (UTC)

For two reasons, I think:

Pages are already slow to load. With more than 1000 statements, things will be very complicated. Actually, this is a wider problem, because some items would most probably need 1000s of statements, so in the long run, performance will have to be improved somehow.
Even when performance is not a problem, having 1000 statements for the same property would make the page rather hard to read. If we can get the same result with just one or two statements per property, that will be clearer. --Zolo (talk) 07:06, 29 March 2013 (UTC)

So you agree that, if it's not planned for now, this isn't an argument for now. Eventually the performance issue will have been addressed and it wont be an issue then either.

Layouts even of sample items like Q159 are hardly ideal, but we have reasonator and more to come. -- Docu at 08:00, 29 March 2013 (UTC)

If the property exists, I do not see why we should not use it for pl:Kategoria:Pochowani na Cmentarzu Powązkowskim w Warszawie. The problems I see with this property are just practical: it should be to easy to automatically recreate the same lists using the place of burial property. That will avoid large and unsightly lists, and also the maintenance work associated with duplication. That seems to me preferable. --Zolo (talk) 20:34, 29 March 2013 (UTC)

This one I'm going to !vote to delete, based on the unwieldiness. There may be some things which should easily and naturally be bidirectional; where someone is buried is not one of them (c.f. en:Arlington National Cemetery). --Izno (talk) 17:51, 29 March 2013 (UTC)
delete I believe some properties should be bidirectional (eg: mother / child), but as Izno says, we aren't going to list every single person who died at Arlington. Legoktm (talk) 13:14, 31 March 2013 (UTC)
delete +1 --Kolja21 (talk) 00:13, 8 April 2013 (UTC)
I think also it is not an ideal solution but some Cemeterys are famous for there personal (Q240744) and there have to be a way to access this information in the corresponding articles - maybe change it to famous people only. --FischX (talk) 11:16, 8 April 2013 (UTC)

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

Attention: The "section resolved" template needs a valid date. The section will not be archived otherwise. Please use {{Section resolved|1=~~~~}} instead.

Property: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 7 days of discussion, consensus is to keep the property. — ΛΧΣ²¹ 18:04, 14 April 2013 (UTC)

contains the administrative territorial entity (P150): (delete | history | links | entity usage | logs | discussion) Usually made items including too many data. For instance, I live in South Dist. Tainan. There 37 districts subdivides into Tainan City, 39 villages subdivides into South Dist. If all subdivides list in the item, the page will be too long to read.. --tntchn ^{Comment · Contribs} 17:00, 7 April 2013 (UTC)

When every city/region is updated with the historical population every year since 1850 to today divided by sex, age, occupation and ethnic groups, they will also be "too long to read". Better to solve that with the possibility to "collapse" such statements. -- Lavallen (block) 05:28, 8 April 2013 (UTC)

Oppose When we say that district Foo is subdivision of region Bar, we should have way to say it in reverse direction - region Bar consist of districts Foo, Lorem and Ipsum. Unfortunatelly, there are also regions which have tens or over hundret subdivisions. JAn Dudík (talk) 10:56, 8 April 2013 (UTC)

Are you opposing deleting the property, or opposing it's usage, hence a delete vote? Legoktm (talk) 15:44, 8 April 2013 (UTC)

For 'Foo is subdivision of region Bar', I would suggest using 'Foo part of (P361) Bar'. Emw (talk) 12:15, 14 April 2013 (UTC)

Keep, per Jan Dudik. We need to be able to say that "this is X, X is broken down into A, B, and C." Courcelles (talk) 21:59, 10 April 2013 (UTC)

Keep, per JAn Dudík. James F. (talk) 11:24, 13 April 2013 (UTC)

Keep, this property provides useful information on place-related items.Jakob ^{Megaphone, Telescope} 17:33, 14 April 2013 (UTC)

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

Attention: The "section resolved" template needs a valid date. The section will not be archived otherwise. Please use {{Section resolved|1=~~~~}} instead.

Property:P430

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--DangSunM (talk) 16:27, 17 April 2013 (UTC)

P430 (P430): (delete | history | links | entity usage | logs) Sorry, wrong type ;(. --Kolja21 (talk) 16:19, 17 April 2013 (UTC)

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

Attention: The "section resolved" template needs a valid date. The section will not be archived otherwise. Please use {{Section resolved|1=~~~~}} instead.

Property:P394

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 - Alright, if this is really depreciated I'm fine with deleting it. I really don't like what's happened with this thread and the one below it; deletion discussions are not the proper forum for discussing which of several implementation options should be used to convey a piece of data, that is a discussion for a more viewed forum such as the community portal or a task force talk page. However it looks like a consensus has settled. Any admin should feel free to undo this without consulting me if they feel that this close is in error. Sven Manguard Wha? 19:17, 28 April 2013 (UTC)

P394 (P394): (delete | history | links | entity usage | logs) Created without discussion.. --Succu (talk) 08:55, 13 April 2013 (UTC)

Keep/Discuss - Origin of the property aside, it seems like a good idea. I'd be willing to keep it around if anyone else here agrees. Sven Manguard Wha? 20:22, 13 April 2013 (UTC)

Redundant: See Wikidata:Properties_for_deletion#Property:P405. --Succu (talk) 20:51, 13 April 2013 (UTC)

Support - I created the property before the creation of Property:P405 - but it is now duplicate. According to "What links here" P394 isn't used anymore, and P405 is used - so keep P405 and delete P394. Eran (talk) 20:00, 26 April 2013 (UTC)

Currently unused => please delete. -- Docu at 12:33, 27 April 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:P405

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 - In the absence of a clear consensus for deletion, I will not delete a property that is in use. It is clear that there are significant divisions as to how best to convert taxon authors, but a deletion discussion is not the proper venue for resolving it. Please take this discussion to the Wikidata:Project chat so that the broader community can reach a consensus on the issue. Sven Manguard Wha? 19:24, 28 April 2013 (UTC)

Question Is there a discussion that overrules the interpretation of the consensus at the item's creation, where the closer says "I understand the proposer's ideal behind using StringValue, but the community thinks this can be done with items"? Sven Manguard Wha? 20:28, 13 April 2013 (UTC)

Liné1 commented: Cannot be an Item because there are standardized author syntax like '(L.) Oken' where L. is the first author and Oken the author renaming. Thats true and only a simple example, but to render ist right two items are required: (L.) Oken. --Succu (talk) 20:47, 13 April 2013 (UTC)

(conflict) Most taxon author are a person if a line see Q1043, it sould be abble to put [[Carl von Linné|L.]] if it is a plant or [[Carl von Linné|Linnaeus]] if it is a animal. I beleive item is the best value for this properties, since generally taxon autor have the notoriety for a article. --Fralambert (talk) 20:56, 13 April 2013 (UTC)

@Succu The best will be a creation of StringValue «botanist autor acronym» and «zoologist autor acronym» to put with the autor. --Fralambert (talk) 21:29, 13 April 2013 (UTC)

This is a complitly other question: L. vs. Linnaeus ist always Q1043. --Succu (talk) 21:39, 13 April 2013 (UTC)

If this would be String wouldn't it be possible to store the Item to the Persons in the References with another extra Property? --Sk!d (talk) 11:06, 14 April 2013 (UTC)

Linking to persons like (L.) Oken would be a nice feature, but it requests a sophisticated new datatype. One that can handle structures like this: (Person1, Person2 & Person3 ex Person4) Person 5 ex Person6 et al. --Succu (talk) 13:32, 14 April 2013 (UTC)

No I don't think that we have to link it. The correct String would be enough. But we could store the information to the items in the references, but I am not sure if this is a valid and wanted use of the references. --Sk!d (talk) 18:17, 15 April 2013 (UTC)

I dont't like bot-created statements like "Quelle=Deuschsprachige Wikipedia". Smart references are another and really complex topic. But please: lets us try this little suggested correction. Its usefull. --Succu (talk) 19:34, 15 April 2013 (UTC)

Couldn't the datatype be a normal string with wiki syntax, like literally "([[Q1043|L.]]) [[Q61993|Oken]]" The user (most likely a Lua-function in the Wikipedias) could then look up the referenced items. Byrial (talk) 11:11, 18 April 2013 (UTC)

Hint: There is a new Property:P428 (botanist author abbreviation). --Succu (talk) 06:57, 19 April 2013 (UTC)

Use of taxon author is described at en:Author citation (botany) and en:Author citation (zoology). It can be done using items and qualifiers, but will be complicated. You will need qualifiers for "year" (zooology), "not original placement" (to place author and possibly year in parenthesis), order of authors if several, "ex" (first publication not valid), "in" (if authorship of the publication is different), "emend." (if changed) and possibly others. A string is much simpler, but has the disadvantage that there will be no direct links to items for the authors. Byrial (talk) 13:10, 26 April 2013 (UTC)
Oppose - hewiki already uses it to link to taxonom. e,g: he:כולכית_מצויה. Eran (talk) 20:03, 26 April 2013 (UTC)

Eran, please read the discussion and understand the problem. --Succu (talk) 20:10, 26 April 2013 (UTC)

I read the discussions both here and in the talk page (creation proposal) and I think item is the correct type for it. Item type allows linking and string doesn't. In non latin Wikipedias the author isn't always specified in latin (fa:شیر_(گربه‌سان), he:האדם_הניאנדרטלי ). String can't be used here... Eran (talk) 20:53, 26 April 2013 (UTC)

You can't handle author citations like Andinobates Twomey, Brown, Amézquita & Mejía-Vargas, 2011 with this property. That's the main point. --Succu (talk) 14:17, 27 April 2013 (UTC)

You can handle citations for this case with Lua: iterating over the items associated with this property, extracting the last names and adding the year as different parameter. The real problem is actually for latin names. Eran (talk) 14:48, 27 April 2013 (UTC)

As a proof of concept: go to en:Andinobates, edit the page, add {{#invoke:Taxobox|taxbox}} and show preview (please dont save - the new taxobox isn't yet ready). Eran (talk) 15:24, 27 April 2013 (UTC)

I found a the wrong author citation (Brown, Amézquita, Mejía-Vargas, Twomey) - parentheses, no year. What about Property:P428 (botanist author abbreviation), special abbr. as "ex", "et al" (see above)? --Succu (talk) 15:40, 27 April 2013 (UTC)

OK I removed the parentheses, but the case is that you can handle multiple authors with Lua, and items can allow correct links, and support i18n (as mentioned before - in non latin wikipedias the author isn't cited the same way). To get botanist abbr we need support either in Lua or with phase 3 queries to get property of linked item (P428 of the author), which isn't yet supported. Regarding et al and ex I'm not sure what is the correct solution here. Maybe we should add to the authors "et al" (or some fake entity) as the author, or define it as a different property. Eran (talk) 16:08, 27 April 2013 (UTC)

Your proposal has other drawbacks. The statement cound be read as four different claims: Brown or Amézquita or Mejía-Vargas or Twomey is the one and only taxon author. --Succu (talk) 14:00, 28 April 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:P378

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. Sven Manguard Wha? 14:22, 26 April 2013 (UTC)

P378 (P378): (delete | history | links | entity usage | logs) Replaced by Property:P421. Could possibly be converted into "UTC offset" as used in en:Template:Infobox country. ---- Docu at 13:13, 14 April 2013 (UTC)

Convert into "UTC offset" sound like a good idea. sv:Mall:Stadsfakta has four parameters for timezone, one for link to article about timezone, one for utc-offset, and two of the same kind for DST. -- Lavallen (block) 14:18, 14 April 2013 (UTC)

I went to Australia and maybe found a problem: UTC+09:30 and others can have some language-related problems. In Swedish time is written as h.m, not h:m. This is technically solvable for a single project, but this can affect several projects. -- Lavallen (block) 17:04, 14 April 2013 (UTC)

I was leaning to keep, given that they have different datatypes, and one can be used as a qualifier for the other. But I'm neutral. — ΛΧΣ²¹ 18:13, 14 April 2013 (UTC)

Delete. Created without discussion, and without any documentation about how time zones should be recorded in a language-independent way. Also seems redundant with Property:P421. I'd welcome a "UTC offset" property, but this should have a quantity datatype, not string, so a new property would need to be created for that. --Avenue (talk) 05:03, 15 April 2013 (UTC)
Delete. --Yair rand (talk) 16:35, 21 April 2013 (UTC)
Delete – Agree with Avenue. Byrial (talk) 13:14, 26 April 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:P293

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 (or more accurately, will be deleted once depreciated). Clear consensus for this. Sven Manguard Wha? 22:20, 7 May 2013 (UTC)

Property:P293 (delete | history | links | logs)
Property:P294 (delete | history | links | logs)

Wrong datatype: should be "Quantity" instead of "String"; as a string, it's completely nonsense. I'll remove and delete it if there's no opposition. --Ricordi samoa 11:13, 5 May 2013 (UTC).

No, you won't: 4-eyes-guideline. —★PοωερZ_{_talk} 11:23, 5 May 2013 (UTC)

It is already used. It is best to use it, as long as we dont have the right replacement. For the user it makes no difference what kind of datatype is used, as long as it is displayed correctly. It only makes a difference, when you try to calculate something. We can delete it after migrating its contents to the future datatype .--Giftzwerg 88 (talk) 11:33, 5 May 2013 (UTC)

Support deletion. So far the community's felt that the number/string dichotomy is one we should respect, and I agree. For instance, if a client project is using {{#property:p293}} m. ({{#expr: {{#property:p293}} * 0.3048}} }} ft.), they shouldn't have to worry about getting big red errors every time someone accidentally puts letters in the Wikidata entry. Oh, and is there any reason that P:P294 isn't included in this PFD? — PinkAmpers&^{(Je vous invite à me parler)} 16:20, 5 May 2013 (UTC)
Support deletion (also for P294) – Better sooner than later, so there will be less to correct then the right datatype is implemented. Byrial (talk) 16:35, 5 May 2013 (UTC)
Wait to delete until the number datatype is actually available, then have a bot copy things over, fixing entries with non-numeric data as it goes. If people want to start collecting this data now, they will need a place to put it. Better to start getting the information in the database earlier, so we can accumulate it faster. We can automatically change it to the "right" format later. —Scott5114 ↗ [EXACT CHANGE ONLY] 06:43, 6 May 2013 (UTC)
Support deletion. It is not easy to track usage of properties in Wikipedias, and if they start using these ones, it will be rather tiresome to switch to new ones. We are not exactly short on work in Wikidata. --Zolo (talk) 06:48, 6 May 2013 (UTC)
Wait until number datatype is available. —★PοωερZ_{_talk} 09:07, 6 May 2013 (UTC)
Support deletion per Zolo. --β₁₆ - (talk) 10:03, 6 May 2013 (UTC)
Support deletion per Zolo. --Nightwish62 (talk) 19:17, 6 May 2013 (UTC)
Support deletion per Zolo. --Stryn (talk) 17:58, 7 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.

Property:P91

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. 3 months is enough time for consensus to form. The pro-deletion arguments were concerns about sourcing, and the opposing arguments are that this property can be used, albeit with the appropriate caution. Even if the arguments of both sides weren't considered, the result has been 4 in favor and 6 opposing deletion, which is not consensus to delete. What both sides agreed on is that sourcing for the use of this property is important, so we must keep that in mind in the future. For future reference, developing Wikidata:Living people would help prevent problems with this property.--Jasper Deng (talk) 05:05, 5 May 2013 (UTC)

moved from Property talk:P91 --Stryn (talk) 13:12, 16 April 2013 (UTC)

Is there any template, that is using this kind of personal stuff? The "Infobox Officeholder" for Harvey Milk has no such info, so Wikidata doesn't need it as well. Please delete or add "Size of penis". Proposed usage guidelines: Use for porn stars and former US Presidents. --Kolja21 (talk) 22:47, 5 February 2013 (UTC)

The key term there is "personal stuff". One's sexual orientation is no more personal than any number of attributes we frequently list. I mean, which do I identify as more? Someone born in Washington, D.C., or someone who is gay? The latter, hands-down. Where does Harvey Milk's notability come from, primarily? Having been a San Francisco councilman, or having been a gay U.S. politician? Sure, the infobox doesn't say it, but it is listed as a category, and Milk appears on List of the first LGBT holders of political offices in the United States; the word "gay" appears 157 times in his article. The day that sexual orientation comes completely non-notable, I'll RFD this property myself, but until then, this is useful data.

As to your other point, for someone like Jonah Falcon, a "size of penis" field could be very useful. Not sure about U.S. presidents, though I can think of at least one case where you could argue it's historically notable. — PinkAmpers&^{(Je vous invite à me parler)} 23:36, 5 February 2013 (UTC)

The info boxes and templates in the English Wikipedia are extremely broad. If we do not limit the properties, there are good reasons to mistrust Wikidata as a kind of open intelligence agency. Right now we don't even have the possibility to add a source, so every property is problematic. To add "sexual orientation" as one of the first poperties is imho irresponsible. --Kolja21 (talk) 06:06, 6 February 2013 (UTC)

Are you honestly suggesting that information about whether or not someone is gay is equivalent to the size of their penis? Because... there's really no rational response to that kind of ridiculousness. Tom Morris (talk) 18:26, 6 February 2013 (UTC)

I propose that we don't use this property (at least not yet) because we have so many opposers: Wikidata:Property_proposal/Archive/1#Sexuality.2FSexual_Orientation. --Stryn (talk) 10:42, 6 February 2013 (UTC)

I'm not clear why the discussion about penis sizes is in the same discussion as keeping or deleting the sexual orientation property, but here's my two cents. The sexual orientation attribute should absolutely stay. Removing it would be a mistake, create more work for us later, and send the wrong message to LGBT editors (sorry, but that particular part of your existence isn't worth noting). Comically, I actually can see the value in penis sizes, but that definitely seems premature to me and not needed now. I also think there's a good debate to be had on the value of that property - but this page is without question not the place to have that debate. --Varnent (talk) 21:36, 6 February 2013 (UTC)

As far as I'm aware there is no requirement for a property to exist in an infobox on wikipedia. Wikidata isn't just about infoboxes, nor is it just about wikipedia. Properties should not be deleted just on the basis that they don't appear in infoboxes. But, it is useful to focus our efforts on infoboxes. Danrok (talk) 23:12, 2 March 2013 (UTC)

This point deserves reiteration: "Properties should not be deleted just on the basis that they don't appear in infoboxes." Wikipedia infobox properties should be neither necessary nor sufficient as a basis for Wikidata properties. Emw (talk) 02:36, 17 April 2013 (UTC)

Support deletion. This kind of property needs very good examples of sources, good use cases, and infobox connection, and non of that is provided. I think there are laws in some countries against keeping track of such things in databases without special permission from the authorities. Mange01 (talk) 23:09, 7 March 2013 (UTC)

Support deletion. Since there are no infoboxes with such a matter, no need in it now. Wikidata is currently and for indefinite time in future is not for categorization, so existence of en:Category:LGBT people (btw prohibited in Russian section although many personalii of it exist and referred as gays in articles) says nothing to such a property. Number of sexual orientations is disputed. Homogenity of historical and modern western kinds of sexuality is strongly disputed. Speaking of person hirself is not a RS. Why on Earth do we need this property and not many others like mentioned by topicstarter? Ignatus (talk) 12:57, 16 April 2013 (UTC)

Comment. I am really unsure about this property, but I would not say that something is relevant a relevant Wikidata property just because it is sometimes important. The sexual life of Harvey Milk or Dominique Strauss Kahn may be important, but I doubt you can say anything relevant about it in Wikidata format (the penis size of a porn star may be a better fit here :) --Zolo (talk) 15:45, 16 April 2013 (UTC)

The point about sexual orientation is that it's not the same as sexual life. If someone identifies as lesbian, gay or bisexual, in many societies that puts them in opposition to the law, popular morality and/or social attitudes... regardless of whether they actually have sex or not. It's an identity category, much like being British—I'm British even if I don't march down the street on St George's Day waving a Union Flag. —Tom Morris (talk) 10:16, 29 April 2013 (UTC)

Support deletion. A property that is only used for only some of its permissible values does not make sense. That means it is poor fit for Wikidata. Also, it is a vandal magnet and we can not enter sources against it. Trapp (talk) 06:21, 17 April 2013 (UTC)

Comment My grumpy comment, copied above, is more than two months old. Since then it has shown that this property is used mainly to stigmatize homosexuals, even if the editors didn't think about it. If the property "sexual orientation" would be used in a non-discriminatory way there should be at least the same number of heterosexuals. There is a fundamental difference between writing about the sexual orientation of a person in an Wikipedia article (incl. differentiation, sources etc.) or creating a database. --Kolja21 (talk) 16:39, 17 April 2013 (UTC)

And what, pray tell, is the difference? What if I want to write a query against the Wikidata database for all self-identified gay people who have won a major scientific award (the Nobel Prize, say)? The presence of categories on Wikipedia for, say, LGBT writers or LGBT comedians allow someone to look for that kind of information.

As for your suggestion that this is even broadly equivalent to penis size, that's absolutely ridiculous. There are organisations that study the history and sociology of LGBT movements. Sexual orientation forms an important part of some people's self-identification: like nationality or religion, identification as being part of a sexual minority can place someone in a particularly uncomfortable or problematic relation with the mainstream of society. If Wikidata is to be a useful database that reflects humanity's difficult relationship with sexuality, we can't whitewash it of sexuality, any more than we can religion or gender or political affiliation or nationality. The historian Richard Davenport-Hines explains the importance of them in his review of David Halperin's book, How to be Gay:

Sexuality and gender are at the heart of understanding human motivation. Treated with intelligence and authorial modesty, the innate differences, indoctrinated codes and enforced disciplines of masculinity and femininity – to say nothing of the sumptuous diversity of sexual inclinations and expressions – should be central to historical understanding. These inspiriting topics underlie many kinds of conduct: aggression, loyalty, fear, altruism, envy, intuition, hatred, creativity.

But, yes, because occasionally people vandalise things, and because of problematic BLP issues on Wikipedia, this is as relevant to inclusion of a database of human knowledge to provide the machine-readable backing for Wikipedia as penis length. What wretched and shallow barbarianism.

Oppose deletion, obviously. —Tom Morris (talk) 20:41, 28 April 2013 (UTC)

Comment There is also some legal issues regarding membership in political organisations. I would not recommend anybody under Swedish jurisdiction to add such information into Wikidata, not even that Obama is a Democrat. Into the article, no problem, but not into a database. -- Lavallen (block) 08:58, 18 April 2013 (UTC)

oppose deletion I view gender identity in the same way that I view religious identity or political leanings in that they are useful identifiers that can be viewed or used both positively or negatively, depending on the intent and pre-existing beliefs of the person doing the viewing or using of the information. That a person's sexual identity can be used to stigmatize and that the data field can be a target for vandalism do not, in my opinion, qualify as reasons that we should not log that information. Sven Manguard Wha? 21:43, 28 April 2013 (UTC)

Probably best to Keep, but I think we really need strict guidelines for when it's okay to use this property. --Yair rand (talk) 19:14, 29 April 2013 (UTC)

Oppose deletion, but I can see a lot of vandals abusing this if they find out about this, so it should definitely be used with extreme caution. T C N7JM 22:07, 1 May 2013 (UTC)

Support deletion. As I predicted this property can be used to diskriminate against special gruops. There are very few people marked as "heterosexuality" so this property is mainly to mark homosexuals. Reminds me on something... a time when gay poeple had to wear a pink badges Q169799.--Giftzwerg 88 (talk) 10:48, 3 May 2013 (UTC)

This isn't used to discriminate, this is used to state facts. This can't really be used to discriminate. Think about it, will an openly homosexual person be mad that the sexuality they've already announced is on this site? It's not like we're deleting their item because they're homosexual or something extreme like that. T C N7JM 12:22, 3 May 2013 (UTC)

Oppose deletion: It's data like every other data, not using it out of fear of discrimination is the real discrimination. And by the way, labels lose their negative connotations by using them in a neutral manner, there is no other way for that. —★PοωερZ_{_talk} 12:25, 3 May 2013 (UTC)

Oppose deletion, but obviously conform to BLP guidelines when using it. ...Jakob ^{Megaphone, Telescope} 21:20, 4 May 2013 (UTC)

Oppose deletion I think PowerZ puts it nicely when it comes to discrimination. If people want to come up with guidelines, I welcome them to comment on my months-old thread on the property talk page. As for the "discrimination" that arises in the property being used more for gay/bisexual people than for straight people... how many people ever actually describe themselves as straight, and get quoted by a reliable source as saying so? Someday in the future, maybe it will be something people say on the record. But for now, it's generally assumed that someone's straight unless they say otherwise. But if it makes anyone feel any better, I just added that Darren Criss is straight, since that is something he's actually publicly acknowledged. — PinkAmpers&^{(Je vous invite à me parler)} 03:53, 5 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.

Property:P402

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 In the absence of a clear consensus, I will not delete an in-use property. It's been two weeks and there clearly isn't a consensus. Sven Manguard Wha? 18:04, 2 May 2013 (UTC)

OpenStreetMap relation ID (P402): (delete | history | links | entity usage | logs | discussion) I'm really happy to see the interest with OSM but we can't do that. OpenStreetMap ID's aren't stable; even less than the Wikidata ones and they are hard to keep it up-to-date. Besides there are not only relations, there are ways and nodes too. It's not humanly possible to keep it up-to-date, we need a bot in permanence for this task. A bot which extract wikipedia tags (openstreetmap:WIWOSM) from OSM in order to keep this property updated. If not relation IDs could be obsolete.. --Otourly (talk) 18:50, 17 April 2013 (UTC)

leaving a link to the original discussion here. Cheers. — ΛΧΣ²¹ 22:26, 17 April 2013 (UTC)

Support under the assumption that it is true about OSM-IDs being unstable. ...Jakob ^{Megaphone, Telescope} 00:52, 25 April 2013 (UTC)
Support deletion, there are no stable IDs in OSM. Some may be more stable than others, but there really is no guarantee that one ID also not one for a relation will stay the same. Because of that there is openstreetmap:WIWOSM that promotes users to tag OSM objects with wikipedia article names. Secondly and I think that would be the way to go there is the OSM-tag wikidata, though not used very often at the moment (see: taginfo). See also: https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID for another solution to permanently link to a OSM object.--Patzi (talk) 13:44, 25 April 2013 (UTC)
Comment I do not see the point of collecting the information in an other Database as a solution specially because wikidata Items are not more stable than OSM realtions also it is about access to geographic information _over_ wikidata. --FischX (talk) 22:42, 25 April 2013 (UTC)
Oppose The fact that these IDs change does not seem like a cogent reason in itself to delete this property. The nominator has even suggested a solution: automate the updates ("extract wikipedia tags (openstreetmap:WIWOSM) from OSM in order to keep this property updated"). Emw (talk) 01:48, 26 April 2013 (UTC)
Oppose OSM Rel IDs are not that unstable. some random examples:
- Q1697 has been connected with relation 51490 which was created in 2010-01-03 and has since then represented the same thing
- Q38 has been connected with relation 365331 which was created in 2009-12-16 and has since then represented the same thing
- Q175117 has been connected with relation 389341 which was created in 2009-29-03 and has since then represented the same thing
right now it seems quite stable to me. I know that its not a perfect solution and we should rather establish a wikidata tag in openstreetmap but on the other hand: lets try it this way around --Shisma (talk) 11:48, 26 April 2013 (UTC)
Oppose It seems that a lot of IDs aren't as unstable as the nominator thought. If the updates can be automated, then this will be a great property to keep. T C N7JM 03:42, 28 April 2013 (UTC)
Comment. This is maybe a matter of definition. You should try to define what stability is first. --Dereckson (talk) 09:07, 28 April 2013 (UTC)
- Indeed. As long as it isn't changing every minute I would think its ok. I think it's more important that we have a system that is able to keep up with the updates, which seems possible. Legoktm (talk) 19:54, 28 April 2013 (UTC)
Comment I think we should work with the OSM team to figure out which property to link with OSM<-->Wikipedia is the most accurate (since it seems like there are multiple options), and then base our property on that. Legoktm (talk) 19:54, 28 April 2013 (UTC)
Keep. --Yair rand (talk) 19:08, 29 April 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:P9

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.

TLDR: No consensus (and therefore no change), with closer recommending that an RfC on Project chat be held after the deployment of Phase III on Wikdata

Long version: There doesn't appear to be a consensus at this time. Supporters of the merge are mainly claiming that one property could serve the role that two do currently. Obviously, in the name of efficiency, and ultimately in the name of long term usefulness of Wikidata data, it is important to get rid of redundant properties. Those opposing the merge, however, make two important counterclaims. First, and the stronger of the two claims in my opinion, is that some languages don't actually have a word/concept for "sibling". As someone who is a native English speaker and culturally "American", I find this a difficult concept to wrap my head around, however I don't know enough to doubt its validity, and I do know from studying other languages that the inclusion or absence of a word or type of word can have a large impact on how concepts that use that word are treated. As Wikidata is multilingual and multicultural, if a large enough subset of languages doesn't have a word/concept for "sibling", that's something that we need to acknowledge and work around. The weaker of the two opposition arguments is that determining whether a sibling is a brother or a sister using only the sibling and gender properties is currently not possible. The reason that I consider this a weak argument is that a) these kind of extrapolations are already being done using outside developed (i.e. Magnus Manske) tools, and b) it would be a monumental failure of phase III queries if they weren't able to do this (eventually). The question of how best to handle siblings is too complicated for a Properties for deletion; in the absence of some significant change, it's always going to wind up no-consensus because both sides have a strong, valid argument. I recommend that an RfC be held on project chat instead. It may be best to wait until Phase III is deployed locally, or at least until we have a better idea of how queries are going to work, before such an RfC is held, as that would resolve one of the two concerns held by the opposition. Sven Manguard Wha? 03:52, 20 May 2013 (UTC)

P9 (P9): (delete | history | links | entity usage | logs | discussion) Merging P9 (sister) with P7 (brother) (rename to sibling); see Wikidata:Project_chat/Archive/2013/04#Merging_Property:P7_and_Property:P9, Wikidata:Requests_for_comment/Kinship and Wikidata:Property_proposal/Person#brother-in-law_.28spouse.27s_brother.29. —★PοωερZ_{_talk} 12:18, 3 May 2013 (UTC).

Strong oppose it's not redundant, it's used a lot here and I want to use it at the Dutch Wikipedia. Dutch doesn't have a word for sibling, we just use brother and sister. Will drop a note for the Dutch community. Multichill (talk) 21:15, 4 May 2013 (UTC)
Strong oppose This proposal results in nonsense to Dutch. P7 <> P9 and sibling is non-existent in Dutch. 37.251.29.44 21:27, 4 May 2013 (UTC)
Oppose -- Based on the above, I must also oppose the merge. T C N7JM 21:38, 4 May 2013 (UTC)
Oppose -- not sure why sibling would be a better choice. AutomaticStrikeout 21:41, 4 May 2013 (UTC)
Oppose unnecessary, and loss of detail. --Rs chen 7754 21:41, 4 May 2013 (UTC)

These points are completely invalid: Wikidata is about machine-readable information. For languages not having a term for sibling the label can always be brother/sister. The linked discussions show a clear consensus to not have sex specific properties, because the sex-property makes them redundant. Templates can always combine sibling and sex to show either brother or sister in Wikipedia. Furthermore there is currently no way to link an intersex person with P7/P9. —★PοωερZ_{_talk} 00:22, 5 May 2013 (UTC) Oh, btw: A decision after half an hour (21:15, 4 May 2013 (UTC) to 21:45, 4 May 2013 (UTC)) of discussion involving five people? You must be kidding. And German has a word for sibling, it's Geschwister.

Wrong. It is not usable in this context. Regards, Vogone talk 11:33, 5 May 2013 (UTC)

[3] [2] fachsprachlich, Singular: eines der Geschwister [1] Falsch, eben doch; aber um Linguistik geht's hier nicht. —★PοωερZ_{_talk} 11:35, 5 May 2013 (UTC)

I'm confused. You want us to combine the "sibling" property with the "sex" property which does not define the "sibling" property but the item itself? That does not tell whether or not it is a sister or a brother. T C N7JM 03:35, 5 May 2013 (UTC)

What are you talking about? I've said by checking both, sibling and sex properties, finding out whether the subject is a sister or brother can be done automatically. —★PοωερZ_{_talk} 04:47, 5 May 2013 (UTC)

I think we should rather wait a bit for more details results of the RFC. The "oppose" arguments above are very weak. There are also languages that do not have a word for sister, but that's not the point. --Zolo (talk) 06:08, 5 May 2013 (UTC)

How is it "not the point"? If there are languages that do not have a word for "sibling", then merging the items is a bad idea. T C N7JM 06:30, 5 May 2013 (UTC)

My concern is more: How to handle items that hasn't been filled with such things as "sex" yet? I have a feeling that we will have a large backlag, since Wikipedia is several years older than Wikidata and is still growing. A large part of the articles do not have a category or an infobox, that a robot can collect information from. On some projects the interest the tecnical ability to construct a robot is limited to a few very busy users. -- Lavallen (block) 06:54, 5 May 2013 (UTC)

There are languages that do not have a word for sister as well. The structure of the kinship voabulary varies widely across the World. Properties are supposed to define relations between items, not what the item is about. "Male" or "female" are attributes of the item themselves, not of the logical relation between them. In this case, the logical relation is "sibling", whether the word exists in all languages or not. Actually I am French and there is no word for sibling in French either, but I cannot see anything wrong with using "brother/sister" instead.

It is possible that the practical reasons for having separate properties for brothers and sisters dominate the logical reason why it is unnecessary, but linguistic reasons alone are not sufficient. --Zolo (talk) 07:02, 5 May 2013 (UTC)

(EC) I don't get it. Why is a perfectly fitting label in every language a criteria for properties? Despite the fact that's pretty much impossible for almost every property, given there are 200+ human languages, the property's actual meaning is of interest to us, not its arbitrary label. —★PοωερZ_{_talk} 07:11, 5 May 2013 (UTC)

In Swedish we have a word for "uncle", but I never hear it. The word for "mothers brother" (morbror) can sometimes also include "mothers brother in-law". To be onest: I do not think this set of properties will ever be used on svwp. -- Lavallen (block) 07:18, 5 May 2013 (UTC)

(EC) A bot should check every person linked by P7/P9 so far for missing sex-statements. If there are any, we can secure this data before merging. —★PοωερZ_{_talk} 07:21, 5 May 2013 (UTC)

You know what? I think I agree with you now. So when is this merger taking place? T C N7JM 07:37, 5 May 2013 (UTC)

Ther will be no merging. We will keep brothers and sisters, the sex can be added in any case and the property can be used for Bots to help.--Giftzwerg 88 (talk) 09:18, 5 May 2013 (UTC)

Strong support – How two people are related (in this case that they share parent(s), and what sex one of them has, is two distinct things which not should be mixed up in a database. A database should have different fields for the relationship and sex, so each user can then combine them as wanted, for instance to match the words in one's language or other purposes. It is impossible to suit all with such predefined combinations of different concepts. To have separate properties for sister and brother can be compared to splitting P:P47 (shares border with) up into separate properties for (shares border with a republic) and (shares border with a monarchy), which I don't hope that anyone would propose. Some may say that it wouldn't work because some countries are neither republics or monarchies, but that keeps the analogy to sister and brother, as you now have no way to indicate intersexed siblings. But the intersex argument isn't the primary one, it is that it is bad to combine two things (kind of relationship and sex) in one property. Byrial (talk) 14:19, 5 May 2013 (UTC)
Support – The argument that a word does not exist in a language is not a good one. Siblingness (having the same two parents) is a property which obviously exists independently of sex. I'm sure it can be expressed in some way or another in any language, even if it is something like "has the same two parents as." --Jfhutson (talk) 14:45, 5 May 2013 (UTC)
Question Could we perhaps resolve this with qualifiers? E.g. <Elizabeth II> sibling <Princess Margaret, Countess of Snowdon>: type of sibling <sister> — PinkAmpers&^{(Je vous invite à me parler)} 16:26, 5 May 2013 (UTC)

I do not see any need for this: once the transclusion syntax is fully deployed, "brother" or "sister" can be easily inferred from the sex of the person. --Zolo (talk) 16:39, 5 May 2013 (UTC)

Support, one "sibling" property will do. If there is a need to use a more specific, gendered word, the item can be queried to determine the subject's gender. Using "brother" and "sister" breaks down when dealing with subjects that identify with non-binary genders. —Scott5114 ↗ [EXACT CHANGE ONLY] 06:38, 6 May 2013 (UTC)
Strong oppose So we should also replace father and mother, son and doughter with "parent" and "child". Makes the world more easy, especialy, when the child has two mothers or changes its gender--Giftzwerg 88 (talk) 07:28, 6 May 2013 (UTC)

Uh ? Yes, if we have just one property for brother and sister we should also have just one property for son and daughter, but this is exactly what we have. --Zolo (talk) 08:16, 6 May 2013 (UTC)
Why is it that none of the opposers actually cared to read the linked discussions? —★PοωερZ_{_talk} 08:45, 6 May 2013 (UTC)
Am I missing something, or is the 'strong oppose' vote above actually arguing in support of the proposed merger? Emw (talk) 02:47, 8 May 2013 (UTC)

support merging, unless someone provides a more sensible reason for having two separate properties. --Zolo (talk) 08:16, 6 May 2013 (UTC)
- I have none, but can the RFC be closed before we start the merging-process? -- Lavallen (block) 08:25, 6 May 2013 (UTC)
  - Agree, this page seems to have more traffic, but the RFC should be the starting point. --Zolo (talk) 08:53, 6 May 2013 (UTC)
    - I personally think it is better to do it in phases. The first phase being merging all redundant sex-specific properties, for which this is the test whether the community is okay with it. Afterwards we can keep on discussion which kinship relations are redundant to each other. —★PοωερZ_{_talk} 13:20, 7 May 2013 (UTC)
Support I can't see why we need two properties when one could do the job very well.--Stevenliuyi (talk) 08:59, 6 May 2013 (UTC)
Strong oppose in French, we don't have a word for "sibling" : we use "frère" (brother), "sœur" (sister) or "frère et sœur" (brother and sister). The word the nearest we have is "fratrie" but it include every child of a person (there is no distinction between "me" and "them", there is only "us"). Ju gatsu mikka (talk) 20:34, 7 May 2013 (UTC)
- Could you also point out why this is a problem? —★PοωερZ_{_talk} 20:36, 7 May 2013 (UTC)
Strong oppose there is often a big difference culturally in what is valid for a brother or a sister.. GerardM (talk) 20:48, 7 May 2013 (UTC)
- What do you mean by this? These properties are used to indicate the biological kinship relation of sharing the same parents. This is a physical reality independent of cultural background. And if I understand you correctly, you are against having separate brother and sister properties as well. —★PοωερZ_{_talk} 20:54, 7 May 2013 (UTC)
Comment – Some opponents argue with what words are available in their language, and that brothers and sisters should be differentiated. Brothers and sisters can still be differentiated after a merge by querying the sex property of the sibling, so I kindly ask these opponents to tell why having separate properties for brothers and sisters should be a better way to organize data than by using independent properties for siblingness and sex. This is not about what data should be available, but about how to best organize the data. Thank you, Byrial (talk) 21:26, 7 May 2013 (UTC)

"Brothers and sisters can still be differentiated after a merge by querying the sex property of the sibling"

If a user speaks a language that does not have a cognate of 'sibling', then how would they query for sibling in the first place? It doesn't seem possible. That is the essence of the Dutch's objection to merging 'brother' and 'sister' into 'sibling'. Emw (talk) 02:41, 8 May 2013 (UTC)

The merged property could be labeled with translations of "brother or sister" or "have at least one common parent", and then you make a query with that property and the sex of the object. Why shouldn't that be possible? Byrial (talk) 07:03, 8 May 2013 (UTC)

Labeling the property "brother or sister" in languages that don't have a term for "sibling" seems like a workable solution. What do the Dutch think of this? Emw (talk) 12:50, 8 May 2013 (UTC)

Again, Wikidata is about machine readable data. You query for P7 in any case. —★PοωερZ_{_talk} 10:18, 8 May 2013 (UTC)

Wikidata is about human- and machine-readable data alike. Could you point me to an example of the query syntax? Emw (talk) 12:50, 8 May 2013 (UTC)

mediawikiwiki:Extension:WikibaseClient/Lua —★PοωερZ_{_talk} 14:45, 8 May 2013 (UTC)

Delete. The extra property supplies absolutely zero additional data. --Yair rand (talk) 22:43, 7 May 2013 (UTC)
Strong support Wikidata should organize data only based on semantics. For Chinese, there is even no brother (or sister), only one character for elder-brother (sister) and another one for younger-brother (sister). We simply put the two characters together when referring to brother (sister). And for sibling, there is a Chengyu(four-character idiom), 兄弟姊妹, just putting these characters together.--凡其 _Fanchy 18:28, 8 May 2013 (UTC)
Support strongly, as per other parts - we shouldn't distinguish semantically-irrelevant properties. James F. (talk) 20:42, 9 May 2013 (UTC)
Support - semantics - ·Add§hore· ^{Talk To Me!} 21:01, 9 May 2013 (UTC)
Support. In terms of a qualifier, I believe that P21 would be sufficient. Regards, Frigid Ninja 22:57, 10 May 2013 (UTC)
Support - I now support the merger based on my comments above. T C N7JM 23:19, 10 May 2013 (UTC)
7 days are over now, but Wait until a bot made sure there won't be any loss of data. —★PοωερZ_{_talk} 00:42, 11 May 2013 (UTC)
- I don't see any clear consensus for doing this. Just close this request to end this nonsense. Multichill (talk) 13:10, 11 May 2013 (UTC)
  - Return to the subject when there is more obvious that this information is available in other ways. Today we do not have the tools to show it. -- Lavallen (block) 13:21, 11 May 2013 (UTC)
  - Well, I see a consensus since the opposers' arguments have been crushed and they don't care to express new ones or even respond. —★PοωερZ_{_talk} 14:46, 11 May 2013 (UTC)
Strong oppose - There is certainly no consensus. I still see no reason for this deletion/renaming. It sounds to me that people from some languages try to enforce that some other languages go find a fictional word, purely based on the arrogance that some languages do have a world for something. We make here an international database which should be human readable as well, and for this important aspect of family relations is no word in many languages, while there is an alternative available that works for almost all languages, if not every language. Why should we replace a property that works (almost) everywhere for some which doesn't work in many languages? I have still not seen any reasonable answer to that question. Wikidata is here for machines and humans, not for machines only. That is forgotten here too much. Romaine (talk) 20:15, 11 May 2013 (UTC)
I think you are arguing against a strawman when you say "try to enforce that some other languages go find a fictional word". No one has said that. For languages where there is not a word for both a brother and a sister, one can put "brother/sister" (or something like that). The reason it should be replaced, as argued above, is that we should attempt to keep "what a person's sex/gender is" separate from "who they are related to". Also, these properties do not handle an intersex relationship, as is noted above. --Izno (talk) 20:29, 11 May 2013 (UTC)

And as has already been said there are languages that do not have a word for "brother" or "sister". If there is arrogance somewhere, it is from people opposing the merger based on no other argument than "wharf, that's not how we do things at home". --Zolo (talk) 06:13, 12 May 2013 (UTC)
Strong oppose completely unnecessary. --Rs chen 7754 20:20, 11 May 2013 (UTC) double vote Vogone talk 20:44, 11 May 2013 (UTC)
Support after reading this discussion, merging P7 and P9 makes sense to me. Regards, Vogone talk 20:44, 11 May 2013 (UTC)

Comment In English wikipedia, I see "A sibling is one of two or more individuals having one or both parents in common". Do we need to differentiate the sibling having one parent in common and the sibling having both parents in common? In Chinese, no simple word for either one. I think if there is also no simple word in most other languages, then it's fair. We just create properties like "has the same parents as" as said above, and "has the same father (mother) as" .

The other reason for this is that it will not generate too much redundancy. Items for a person probably don't have P:P22 and P:P25. Having one or both parants in common cannot be determined like brother and sister for these persons. --凡其 _Fanchy 17:03, 12 May 2013 (UTC)

I have until now understood both the brother and sister property to mean "having at least one parent in common", but the precise meaning is not stated on the talk pages of the properties, and I don't know of any discussion about if halfbrothers and halfsisters are included or not. That should be determined no matter the result of this merge discussion. Byrial (talk) 17:28, 12 May 2013 (UTC)

If we continue down either path described in Wikidata:Requests for comment/Kinship#Proposed systems, we won't have to have this ambiguous property either. Siblingness is always a function of parentage. --Jfhutson (talk) 14:08, 14 May 2013 (UTC)

Support Properties that can be trivially deduced from other properties should not exist. My main concern about the proposed merger has been addressed: labeling the property "brother or sister" in languages that don't have a term for "sibling" seems like a workable solution. Emw (talk) 02:18, 15 May 2013 (UTC)
Oppose These properties (brother/sister) cannot be "trivially" deduced from the other properties (like sibling and sex), because you would have to query the property of another item, which is not yet possible using {{#property:}} syntax. Even if this feature will be developed in the future, I still think it's a good idea to have separate properties for brother and sister, because in many languages (including French, Dutch, Romanian, etc) there is no word for "sibling" (and it would be awkward to have a property named "brother or sister"). Also, sometimes redundancy is a good thing, for performance reasons and for providing another way to double-check the correctness of data. Rsocol (talk) 07:27, 15 May 2013 (UTC)

How is a query like 'get items that are siblings of the subject and female' not trivial? I don't see the fact that query syntax is unavailable as a significant issue: if it is, then it will be moot in a few weeks. Are there any large-scale implementations of P9 that need to differentiate siblings between sex, which would be disrupted if P9 were merged before query syntax is available?

The points about the benefits of redundancy with regard to performance and validation need further explanation. Noone would dispute that redundancy can sometimes be help performance, but why would it do so in this particular case? And wouldn't redundancy of this sort introduce at least as much potential for inconsistent data as it would potential for consistent data? Unless there are compelling reasons to keep this redundant property, I think the more succinct, normalized option should be preferred. Emw (talk) 01:43, 16 May 2013 (UTC)

The query "get items that are siblings of the subject and female" may be easily expressed in plain english, but try to write it in a computer language (any computer language that supports Wikidata querying). Redundancy may be useful in this case because using a query for the "sister" property directly (instead of using a compound query, based on "sibling" and "sex") may probably use an index or some pre-cached data. If we use the "brother" and "sister" properties (as well as "sex"), inconsistent data may be more easily detected (by a bot) and after that they will be corrected (by a human); without the brother/sister properties, inconsistent data in the "sex" property may only be detected by a human or by comparing the data with external sources (such as Wikipedia or other sites). Rsocol (talk) 20:14, 16 May 2013 (UTC)

Support not more redunancy than necessary. --Pyfisch (talk) 19:00, 15 May 2013 (UTC)

Support Redundant. --Succu (talk) 06:30, 17 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.

Property:P482

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. Sven Manguard Wha? 23:18, 14 May 2013 (UTC)

P482 (P482): (delete | history | links | entity usage | logs) I think it's not necessary to distinguish between property "starring" (Property:P161 and "support actor/actress" in the top-level of statement. It's better to list all actors (whatever starring or not) in one list, than add qualifiers (in example '<as> <starring role>' or '<as> 'support actor'). There are multiple reason for that, e.g.:

the order of the statements are due to the entering time. This means, both statements could be scattered over the item page.
how should we handle when importing actors from external databases? With two properties, we've to decide the actors should either be important to starring or supporting property. I don't think it's possible to automatically recognize the right type of role. With only one property 'actors', actors can be important to this property and information (qualifier) about starring role or not can be enter later manually?

Therefore I would delete the new property and rewrite the description for P161 from "starring" to "actor/actress". --Nightwish62 (talk) 10:43, 5 May 2013 (UTC).

Support also because not all the wiki split in starring and support actor. --ValterVB (talk) 22:42, 7 May 2013 (UTC)
Support merging with P161 pr. Nightwish62 (The sources may not differentiate) --Byrial (talk) 06:53, 8 May 2013 (UTC)
Support merging with P161. James F. (talk) 20:41, 9 May 2013 (UTC)
Support per Nightwish62 and ValterVB. --Ricordi samoa 21:31, 12 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.

Property:P280

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. Sven Manguard Wha? 01:12, 15 May 2013 (UTC)

P280 (P280): (delete | history | links | entity usage | logs) Hard to know exactly what this was intended to be used for but it is not used as part of any claims so far as I can tell (its only where used appearances are in lists of properties). Based on the label though, I don't think it would pass muster as a property proposal, and with it not being used, it should be deleted. Joshbaumgartner (talk) 05:45, 12 May 2013 (UTC).

Unused => Please delete. -- Docu at 06:58, 12 May 2013 (UTC)

Support deletion. According to User talk:EUvin#New properties it is intended to describe languages. Maybe a property for that can be useful, but the datatype if needed should be the item for the book, not Commons file as here, so it created with wrong datatype. Byrial (talk) 07:15, 12 May 2013 (UTC)
Support as an unused property....Jakob ^{Megaphone, Telescope} 11:25, 12 May 2013 (UTC)
Support as I also didn't understand the purpose of this property --Nightwish62 (talk) 12:22, 12 May 2013 (UTC)
Support deletion. Basically it's trivia, and practically it's impossible to define - natural languages evolve and there is rarely a clear first book, so it can only be used in reality for a handful of artificial languages. DGtal (talk) 21:30, 13 May 2013 (UTC)
Support deletion as unused and unnecessary. AutomaticStrikeout 00:24, 14 May 2013 (UTC)
Support deletion. Unused, unnecessary property. LlamaAl (talk) 00:35, 14 May 2013 (UTC)
Support deletion. I'm not really sure why this matters to items concerning authors or how it could be used usefully. T C N7JM 11:31, 14 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.

Property: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.

Not deleted - no consensus to delete after one week of discussion.--Jasper Deng (talk) 16:59, 20 May 2013 (UTC)

image (P18): (delete | history | links | entity usage | logs | discussion) An image is not really a clearly defined property. An object (f.e. building) can have millions of different images representing it. We do not need to centralize the image of an object on wikidata, every language version should have the artistic freedom to choose it's own representation. It would be boring to see articles in every language version using the same image. This property is already misused, f.e. Avignon.--Sinuhe20 (talk) 21:23, 12 May 2013 (UTC).

Support deletion. --Succu (talk) 21:32, 12 May 2013 (UTC)
Oppose 1.) better to use a generic image property with qualifiers (<One World Trade Center> image <picture.jpg> shows <opening ceremony>), than have thousand of specific image-property (<One World Trace Center> opening ceremony image <picture.jpg>) 2.) every language version should have the artistic freedom to choose it's own representation. It would be boring to see articles in every language version using the same image ? Sorry, but collection image information centralized doesn't mean every Wikipedia use the same picture?! --Nightwish62 (talk) 17:37, 13 May 2013 (UTC)
But a generic image is not a well defined property of an item. There can be several opening ceremony images, who says that the chosen is the right one? All other properties are well-defined: capital of a country, population, area size... Images are making at most sense, if you have a specific purpose, f.e. an album cover. I think there are not too many useful cases for defining an image as property.--Sinuhe20 (talk) 17:58, 13 May 2013 (UTC)
Sometimes, we have a lot of images about a topic in Commons, and some are fairly obviously better than others. It is true that is is somewhat subjective, but so is choosing an image in an infobox is subjective. I suppose there could be item by item discussions in some cases. Also, we could probably have guidelines like giving priority to "valued images". --Zolo (talk) 19:38, 13 May 2013 (UTC)
Support per Sinuhe20's above comment. ...Jakob ^{Megaphone, Telescope} 19:15, 13 May 2013 (UTC)
Oppose. Qualifiers, and more specific properties may be useful, but this property makes sense but for many "image" parameters in infoboxes. If small languages want to automatically create infobox, they should be able to do it without the need to look for the most appropriate one in Commons. Fairly often the variety in Wikipedia images is due to some languages using older, lower quality images, rather than to a deliberate choice. And if it is a deliberate choice, Wikipedias can always override Wikidata. --Zolo (talk) 19:33, 13 May 2013 (UTC)
Images in infoboxes are mostly not mandatory. Wikidata should only provide basic data, being essential for the item. Because this property is so subjective, it could lead to a lot of discussions and edit-wars.--Sinuhe20 (talk) 21:03, 13 May 2013 (UTC)
Weak support. Saving choosing an image is useful, but in my experience, different images are better suited to different wikis, as they are often culturally different. This is obvious in places like Jerusalem, where Hebrew will probably prefer Western wall, Arabic Al-Aqsa mosque and Latin a Church. Portraits of people are easier in this question, so maybe limiting it to Pics of people, stars, plants and animals cab be helpful. DGtal (talk) 21:40, 13 May 2013 (UTC)
Oppose deletion. To create infoboxes automatically with wikidata an image of the object is essential. --Pasleim (talk) 22:21, 13 May 2013 (UTC)
Images are mostly not essential for infoboxes. By the way, the first aim of Wikidata is to provide consistent data, not the automatic creation of infoboxes. Take an example: Pyrit has the image File:2780M-pyrite1.jpg, which is solely used in en.wp. de.wp, fr.wp and es.wp are using completely different images, but everyone wants to use wikidata for creating infoboxes. So images are the only elements that differ in the infoboxes, they cannot be centralized.--Sinuhe20 (talk) 08:32, 14 May 2013 (UTC)
Oppose but use it with care. It's not a property for the average item. It's useful in the work-domain, less so in the place-domain. -- Lavallen (block) 06:34, 14 May 2013 (UTC)
Oppose deletion. I think linking items to commons (and vice versa) is useful data. We don't need to show/use it all but it's all good. Secretlondon (talk) 11:56, 14 May 2013 (UTC)
Support — we have the Commons category link property to serve this purpose. —Scott5114 ↗ [EXACT CHANGE ONLY] 11:04, 15 May 2013 (UTC)
Weak oppose — artistic freedom is possible for many properties, and most infoboxes with images only have one image; if there is an edit war, you can specify images locally or delete the property from the item. --AVRS (talk) 14:50, 15 May 2013 (UTC)
(weak because of screenshots in articles on Firefox) --AVRS (talk) 15:03, 15 May 2013 (UTC)
Support - I've wondered why we have a generic "image" item. I might understand something like Property:Logo, but image seems not only unnecessary but almost totally useless. Most items will or do have a commons category associated with them as well. --Izno (talk) 02:00, 17 May 2013 (UTC)
On a side note, the "best" image from a photographic standpoint ("valued image") is not always the lead image. Maybe a separate property could be "valued image of this topic" or something, but that kind of leads us down the road of stuff like {{GA icon|es}}, etc. (Which I believe we'll be adding at some point from what I understand.). --Izno (talk) 02:04, 17 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.

Property:P96

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 --Ricordi samoa 06:47, 15 May 2013 (UTC)

P96 (P96): (delete | history | links | entity usage | logs) unused, superseded by "parent astronomical body (P397)", "child astronomical body (P398)" and "companion of (P399)" --Ricordi samoa 21:29, 12 May 2013 (UTC).

Support deletion. Unused, obsolete property. LlamaAl (talk) 00:37, 14 May 2013 (UTC)
Support deletion, of course. --Paperoastro (talk) 11:36, 14 May 2013 (UTC)
Support--DangSunM (talk) 01:21, 15 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.

Property:P388

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 Sven Manguard Wha? 06:04, 17 May 2013 (UTC)

P388 (P388): (delete | history | links | entity usage | logs) All singles which are part of the same album (or are by the same artist) should be obtained with a query, after being listed as "by author X" or "part of album X"; at the time of property creation, we probably didn't think of queries, but now we should avoid "replication" of infobox parameters: many of them are really unneeded. --Ricordi samoa 20:49, 13 May 2013 (UTC).

Support Redundant. —★PοωερZ_{_talk} 01:45, 14 May 2013 (UTC)
Support -- I agree, this is pretty redundant. T C N7JM 12:07, 14 May 2013 (UTC)
Support, better handled by queries. —Scott5114 ↗ [EXACT CHANGE ONLY] 11:05, 15 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.

Property:P519

P519 (P519): (delete | history | links | entity usage | logs) Wrong Datatype, needs to be string. --MichaelSchoenitzer (talk) 21:42, 14 May 2013 (UTC)

Done --Stevenliuyi (talk) 21:50, 14 May 2013 (UTC)

Property:P116

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, clear consensus. --Ricordi samoa 22:32, 16 May 2013 (UTC)

P116 (P116): (delete | history | links | entity usage | logs) As for P96: unused and superseded by "parent astronomical body (P397)", "child astronomical body (P398)" and "companion of (P399)" --Paperoastro (talk) 11:01, 15 May 2013 (UTC).

Support--DangSunM (talk) 13:04, 15 May 2013 (UTC)

Support, of course. --Ricordi samoa 15:07, 15 May 2013 (UTC)

Support deletion. Per the same reasons as P96. LlamaAl (talk) 19:07, 15 May 2013 (UTC)

Support - Byrial (talk) 18:59, 16 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.

Property:P99

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

Deleted consensus plus provided reason are valid and clear. John F. Lewis (talk) 19:17, 17 May 2013 (UTC)

P99 (P99): (delete | history | links | entity usage | logs) I have orphaned this property. To be deleted as P96 and P116: superseded by "parent astronomical body (P397)", "child astronomical body (P398)" and "companion of (P399)" --Paperoastro (talk) 21:31, 15 May 2013 (UTC).

Support – to continue the transition to P397/P398/399. Besides P99 was easy to misunderstand/misuse as is discussed at Property talk:P99. Byrial (talk) 18:58, 16 May 2013 (UTC)
Support, per the above discussions. --Ricordi samoa 22:28, 16 May 2013 (UTC)
Support deletion. Per the same reasons as P96 and P116. LlamaAl (talk) 02:46, 17 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.

Property:P510

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, which I have carried out with. Regards, — Moe Epsilon 07:34, 23 May 2013 (UTC)

P510 (P510): (delete | history | links | entity usage | logs) No consensus. —★PοωερZ_{_talk} 02:05, 20 May 2013 (UTC).

Delete. --Yair rand (talk) 02:08, 20 May 2013 (UTC)
Also of interest. Docu (talk • contribs • logs) violated property policies multiple times now. —★PοωερZ_{_talk} 04:29, 20 May 2013 (UTC)

Delete I can't see why this was approved and it goes against sibling discussion. Secretlondon (talk) 13:09, 20 May 2013 (UTC)

Delete Stop with family properties. Snipre (talk) 17:23, 21 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.

Property:P445

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.

This and the entry below it have a solid consensus for deletion. I've done the changeover myself (at least in the mainspace), so I'm hitting the killswitch. Sven Manguard Wha? 07:17, 23 May 2013 (UTC)

P445 (P445): (delete | history | links | entity usage | logs) P445 (P445) | Redundant to review score (P444) and review score by (P447). —★PοωερZ_{_talk} 02:23, 20 May 2013 (UTC).

Support. --Stryn (talk) 11:47, 20 May 2013 (UTC)

Delete redundant. Snipre (talk) 17:26, 21 May 2013 (UTC)

Delete. --Yair rand (talk) 23:57, 22 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.

Property:P446

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. Sven Manguard Wha? 07:12, 23 May 2013 (UTC)

P446 (P446): (delete | history | links | entity usage | logs) P446 (P446) | As above. Redundant to review score (P444) and review score by (P447). —★PοωερZ_{_talk} 02:24, 20 May 2013 (UTC).

Support. --Stryn (talk) 11:46, 20 May 2013 (UTC)

Delete Snipre (talk) 17:28, 21 May 2013 (UTC)

Delete Danrok (talk) 23:51, 22 May 2013 (UTC)

Delete. Redundant. --Yair rand (talk) 23:56, 22 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.

Property:P46

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.

~~Depreciation in progress, will be deleted when all entries using P46 are converted to P6. Sven Manguard Wha? 19:20, 24 May 2013 (UTC)~~

SamoaBot has

finished the mass-migration of all claims (example) --Ricordi samoa 22:55, 24 May 2013 (UTC)

And now it has been

Deleted by Sven Manguard (talk • contribs • logs). --Ricordi samoa 22:56, 24 May 2013 (UTC)

(edit conflict)(edit conflict) Deleted Sven Manguard Wha? 22:58, 24 May 2013 (UTC)

P46 (P46): (delete | history | links | entity usage | logs) According to the discussion we should have only one property for head of government on any level. Hence I suggest merging this property with Property:P6 which is used in more items.. --Šlomo (talk) 19:32, 7 May 2013 (UTC)

Support and also suggest merging Property:P169 to make a general organization executive head property. --Jfhutson (talk) 19:44, 7 May 2013 (UTC)

A Swedish municipality has no "goverment", and therefor no "head". This will look awful back home... -- Lavallen (block) 19:44, 7 May 2013 (UTC)

According to what I found there is something in the Swedish municipalities called kommunalråd or kommunstyrelsens ordförande. The (merged) property when applied to a Swedish municipality should probably point to the person occupying this position. The exact translation of the general term as well as of the particular cases should be the question of labels in various languages and of the use of the property in particular Wikipedia (or wherever...)--Šlomo (talk) 20:47, 7 May 2013 (UTC)

Well, it does not have to be beautifull, it just have to work. But I hope the kommundirektör of a municipality will not be merged with this property, otherwise Wikidata will be useless for this purpose.

There is also problems with describing a "landshövding" as the "head of goverment" of a county. He/she is more of a "head of state" for the county, than a head of goverment. -- Lavallen (block) 05:09, 8 May 2013 (UTC)

It seems to me there is certainly a difference between head of government of a territory and head of an organization, so I retract my suggestion to merge Property:169. I suppose ideally we would create a separate item for each government, since a government is a different thing than it's territory, but that doesn't seem feasible. I don't understand the difference between a head of state and head of government. --Jfhutson (talk) 15:37, 8 May 2013 (UTC)

You will find an explanation of the difference in the introduction in the Wikipedia article en:Head of state. Byrial (talk) 15:46, 8 May 2013 (UTC)

Interesting. I suppose there should be separate properties for head of state and head of government, and apparently the POTUS would get both. Anyway, the property should not be based on the level of government, as it is now. --Jfhutson (talk) 15:57, 8 May 2013 (UTC)

There already is different properties for head of state (P:P35) and head of goverment (P:P46). This discussion is about merging the latter with head of local government [[P:P6]. Byrial (talk) 16:15, 8 May 2013 (UTC)

Support merge but oppose outright deletion. Head of government could be useful. ...Jakob ^{Megaphone, Telescope} 19:49, 7 May 2013 (UTC)

Support merge I see no point in having different properties for this dependent on the level of government. That is to mix different concepts: the head of government, and the administrative level of the government. These concepts should have independent properties. Byrial (talk) 21:06, 7 May 2013 (UTC)
Support merge and deletion per above. Defining the level of government should not fall in the scope of this property. I'm planning a Python script to migrate all values. --Ricordi samoa 21:06, 8 May 2013 (UTC)
Support Things have changed a lot since early February, when James created this property and I proposed the regional government one. This was all before the community decided to merge all of the administrative subdivision properties, and before any of us really understood what Phase II was gonna look like. So yeah, this is a vestige of an earlier understanding of the property scheme, and should be removed. — PinkAmpers&^{(Je vous invite à me parler)} 00:30, 9 May 2013 (UTC)
Support merging P6 into this more general term as I argued right from the start. :-) James F. (talk) 20:39, 9 May 2013 (UTC)
Support merge, no need for different properties for heads of different levels of government. --Avenue (talk) 02:02, 10 May 2013 (UTC)
Support merge with resulting property titled "head of government". AutomaticStrikeout 15:00, 11 May 2013 (UTC)
Support merge. Having two of nearly the same property isn't necessary. T C N7JM 18:28, 11 May 2013 (UTC)
Comment, a general "headed by" property sounds reasonable, but we should have guidelines to differentiate between several roles. For instance, many states have a "Head of State" and a "head of government", French départements have a "président du conseil général" and a "préfet", companies often have a CEO and a chairman. --Zolo (talk) 11:47, 14 May 2013 (UTC)
Comment How about a head property to indicate a head for this unit, with a qualifier of office? So, for London it would be head = Boris Johnson, qualifier office = Mayor of London. Could also work for organizations, and allow for other offices/positions to be indicated without having to set-up new properties. Danrok (talk) 13:33, 20 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.

Property:P601

P601 (P601): (delete | history | links | entity usage | logs) Wrong datatype.

Deleted --Stryn (talk) 20:50, 6 June 2013 (UTC)

Property:P603

P603 (P603): (delete | history | links | entity usage | logs) Wrong datatype. I don't know whats wrong, I took 'String' as datatype but the created property has datatype 'item'. Wtf? Won't try agin, some other has to create the NUTS-property. -- MichaelSchoenitzer (talk) 22:08, 5 June 2013 (UTC)

Deleted --Stryn (talk) 20:50, 6 June 2013 (UTC)

Property:P41

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 a consensus if not to keep this, at least that right now it's the best of several sub-optimal solutions, which is itself essentially an argument to keep (albeit not a great one). So KEPT. Sven Manguard Wha? 02:06, 1 June 2013 (UTC)

flag image (P41): (delete | history | links | entity usage | logs | discussion) flag image (P41) | Redundant to flag (P163) and image (P18). —★PοωερZ_{_talk} 02:34, 20 May 2013 (UTC).

Question How is that? So one could use flag (P163) with the value "empty" and add image (P18) as qualifier?
Have you attempted to do that lately? -- Docu at 08:05, 20 May 2013 (UTC)

Why would it ever need to be set to "empty"? Why not just create an item for it if it doesn't have one? --Yair rand (talk) 08:26, 20 May 2013 (UTC)

So User:23PowerZ would be creating these empty items? Or a new interface feature? How would it practically work for our contributors? -- Docu at 08:34, 20 May 2013 (UTC)

Here is an example item flag (P163) links to. Articles about flags are relevant according to Wikipedia's guidelines and most of them already got one anyway. —★PοωερZ_{_talk} 13:36, 20 May 2013 (UTC)

Hmm .. interesting when we see you write "most". What do you mean with that? What do you base your explanation on? What Wikipedia guideline do you mean? I think you are actually driving-by another website than you have in mind. -- Docu at 13:53, 20 May 2013 (UTC)

I point you to Wikidata:Notability, flags are notable. —★PοωερZ_{_talk} 13:59, 20 May 2013 (UTC)

Hmm, this isn't an irrelevant Wikipedia guideline you mentioned. It doesn't explain your claim "most of them already got one anyway" either. Is this drive-by thing the result of closure of the P:P9 discussion? -- Docu at 14:03, 20 May 2013 (UTC)

What are you talking about? The image of a flag is a property of the flag itself, therefore flag image (P41) is redundant. —★PοωερZ_{_talk} 14:10, 20 May 2013 (UTC)

I'm asking you to provide evidence for your claims, notably "most of them already got one anyway". -- Docu at 14:19, 20 May 2013 (UTC)

E.g. w:Wikipedia:WikiProject_Heraldry_and_vexillology/World_Flags. —★PοωερZ_{_talk} 14:24, 20 May 2013 (UTC)

So meant to say "most of the 500" on your website? -- Docu at 14:26, 20 May 2013 (UTC)

Could you please come back to a rational discussion? I have no idea what you actually mean. For a complete list of flags with description pages see w:Category:Flags. —★PοωερZ_{_talk} 14:30, 20 May 2013 (UTC)

Changes like these should have been proposed elsewhere, prior to any delete process. This property is already live on wikipedia, so it should not be deleted until another method is discussed and in place. Danrok (talk) 14:33, 20 May 2013 (UTC)

We are stilling trying to figure out how you, 23PowerZ, came to write "Articles about flags are [..] and most of them already got one anyway. ". Now you pointed to a list of about 500 articles on en_wiki to illustrate that most flags already have an article. Is this all you have to support your POV? -- Docu at 15:15, 20 May 2013 (UTC)

You are still trying to do that. All the rest of us are discussing why P41 is or isn't redundant and whether we should delete it. —★PοωερZ_{_talk} 15:21, 20 May 2013 (UTC)

So you are withdrawing your comment? Fine with me. You should probably withdraw your drive-by nomination as well. -- Docu at 15:44, 20 May 2013 (UTC)

No, but that was an irrelevant side note to your ridiculous question, showing you didn't understand why P41 is redundant. Even if there were not a single flag article on any language Wiki, P41 would still be redundant. —★PοωερZ_{_talk} 15:48, 20 May 2013 (UTC)

Hm, can image (P18) really narrow enough that this would work well? I imagine that "flag image" is specifically used for images that are the flag design, and not, say, a photograph of a flag waving. --Yair rand (talk) 08:26, 20 May 2013 (UTC)

The best flag image available should be used (a crap photo is fine, if that's all there is). As it happens, Commons has flags well covered, so we have lots of nice vector images. Danrok (talk) 14:01, 20 May 2013 (UTC)

Good point. Delete. --Yair rand (talk) 11:50, 23 May 2013 (UTC)

Comment I think flags should be paired up with qualifiers, and a description item created if needed. So, that there is no mistake as to which flag belongs with which description. Some items have more than one flag. For example: Flags of Elizabeth II. Same would apply to coat of arms. Danrok (talk) 14:07, 20 May 2013 (UTC)

Same applies to logo, seal, and any other symbol image property. Danrok (talk) 14:09, 20 May 2013 (UTC)

I think the deletion proposer thinks you should be creating thousands of items and use the image property there. -- Docu at 04:04, 23 May 2013 (UTC)

Surprisingly, me thinks that too. But in contrast to you I know we already have these items. —★PοωερZ_{_talk} 10:53, 23 May 2013 (UTC)

Maybe you have for some projects, but not all of them. As far as I know, on svwp there is more or less the same article for all flags in Africa. There is no possibility to create a link to that article until the system allows redirects as sitelinks. -- Lavallen (block) 12:28, 23 May 2013 (UTC)

It's kind of odd that we still haven't seen any evidence of this. Seems to be just empty talk. -- Docu at 18:50, 23 May 2013 (UTC)

How would you create a link to correct article when there is no sitelink? -- Lavallen (block) 18:53, 23 May 2013 (UTC)

If there is "item A with flag description property" => "item B for flag article with property for flag filename" => "flag filename",
it should be possible to display on an article for "item A" in any language "flag filename".
"item B" needs to exist and Z still hasn't provided us with any evidence for that. Otherwise, all need to be created.
One could use an empty "flag description property" and add as qualifier the "image" property there with "flag filename", but this isn't as convenient as P41. -- Docu at 19:20, 23 May 2013 (UTC)

I gave you an example of a flag item, I gave you a complete list of existing flag articles on enwp, I pointed you to WD:Notability, showing you flag items are notable, and therefore will be created eventually anyway, if they don't exist already. The image of a flag is a property of the flag itself, we can show that with P18, and that's what we should be doing. Now you make a case why P41 isn't redundant and shouldn't be deleted, other than "I like it." and "Status quo is always preferable." —★PοωερZ_{_talk} 23:31, 23 May 2013 (UTC)

Comment I'd suggest finding out how infoboxes on wikipedia can be populated using wikidata before deleting any of these properties. The template which handles that may need to be changed. Danrok (talk) 14:16, 20 May 2013 (UTC)

Maybe you should find out first and request deletion afterwards. -- Docu at 04:04, 23 May 2013 (UTC)

I haven't started any deletion requests, and I'm suggesting that those who do should be thinking more before doing so because deletion may break something on wikipedia. Danrok (talk) 19:21, 23 May 2013 (UTC)

Sorry, I misunderstood. Would you change your "support" above to "keep"? -- Docu at 19:25, 23 May 2013 (UTC)

Comment I have discovered that some of the files used in some items are not real flags, they are a banner of arms (Q806865). I am not sure that P163 is relevant for all of them. In many cases coat of arms (P237) is more relevant. -- Lavallen (block) 11:23, 23 May 2013 (UTC)

Comment I have removed usage of this property from en:United States. I do not think that there are many direct uses of properties in the main namespace, but sometimes they are used as showcase on high-traffic pages. We would really need a bot. -Zolo (talk) 11:36, 23 May 2013 (UTC)

Keep for now, until all flag images have been moved to another property. Danrok (talk) 23:48, 23 May 2013 (UTC)

Keep Most flags don't have articles in Wikipedia and this would require our users to create a new item each time they would want to add a flag. Creating numerous new items we may not even know how to name isn't user friendly at all. -- Docu at 06:31, 26 May 2013 (UTC)

Keep - most of flag files used in infoboxes are flags of municipalities which have no related articlee about. now in infobox can be used simple {{#property:P41}}. If this item is deleted, we must use more complicated form. Not every user is good in programming. JAn Dudík (talk) 20:09, 29 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.

Property:P48

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.

Deletion pending - Once a bot has processed this and made the needed changes, this will be deleted. Sven Manguard Wha? 02:09, 1 June 2013 (UTC)

Done Hazard-SJ ✈ 05:15, 1 June 2013 (UTC)

P48 (P48): (delete | history | links | entity usage | logs) P48 (P48) | Is redundant to audio (P51) and anthem (P85). —★PοωερZ_{_talk} 20:05, 19 May 2013 (UTC).

Delete it's redundant and hasn't been in massive use by now. دوستدار ایران بزرگ (talk) 07:51, 23 May 2013 (UTC)
Delete Danrok (talk) 14:35, 23 May 2013 (UTC)
Delete, but weakly. Seems mildly redundant. AutomaticStrikeout 03:11, 24 May 2013 (UTC)
Info: Since consensus appears to be reached, I'm developing a script to quickly remove this property from items
– only if item.p48 == item.p85.p51, of course. --Ricordi samoa 07:43, 25 May 2013 (UTC)
So now all the information has been deleted. Who is responsible for restoring the links? Infovarius (talk) 15:18, 1 June 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:P131

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 a consensus for keeping this. It should be noted that, in my view at least, in the absence of any additional factors/details, that a property is heavily used is not in and of itself a valid reason for keeping a property. If viable alternatives are presented, bots can do the changeover. However Scott5114's argument was a valid reason to keep the property, and -Rschen7754 and AutomaticStrikeout echo the same point. Sven Manguard Wha? 01:49, 1 June 2013 (UTC)

located in the administrative territorial entity (P131): (delete | history | links | entity usage | logs | discussion) located in the administrative territorial entity (P131) is redundant to part of (P361) and the use of P132 (P132) or instance of (P31). Also contains the administrative territorial entity (P150) is redundant to the use of has part(s) (P527) together with P132 (P132) or instance of (P31).. The definition of an "administrative unit" is to vague to be of any help. Observe that these properties are already used by Wikipedia. The posibility to write: {{#property:P132|of={{#property:P361}}}} do not exist yet, neither is there any such tools in the Lua-modules yet. Therefor is there no posibility to merge these properties until such tools exist. But I would like to have a serious discussion about the limitation to "administrative units" in some properties. -- Lavallen (block) 07:56, 21 May 2013 (UTC)

I've been using this to mean 'is physically located in'. It is different from 'is part of'. For example Balkhash Radar Station is part of Main Centre for Missile Attack Warning but is in the administrative unit Karagandy Province. Secretlondon (talk) 11:47, 21 May 2013 (UTC)

According to the description of the properties you're probably right, as for now. But I strongly agree that we need a serious discussion on this field about which properties we need and how should we use them. I can see three cardinal question which should be cleared in the beginning, but feel free to add more:

Do we need different properties for geographical and "other" items? And if so, then on the next level: Do we need different properties for administrative and "other" types of geographical structuring (fiscal, juridicial, statistical a.s.o.)? And also: Do we need different properties for general terms and instances? In other words, do we need different properties to say that Scandinavia is part of Europe, that a particular municipality is a part of a particular district, that Charles Baudelaire is one of the poetes maudits, that Operation Barbarossa is part of WWII and that a drive shuft is a part of clutch, or can we use one general property "part of" with appropriate qualifiers when necessary?
Do we need different properties for connecting the units of similar character (making thus some kind of structure) and for connecting some item with it's context (geographical, social a.s.o.)? In other words, do we need extra properties to say that Manhattan is in New York City and to say that Empire State Building is in New York City?
Do we need separate properties for reciprocal relations? In other words, do we need to say both that Bavaria is in Germany and that Germany includes Bavaria, or is one statement (and consequently one property) enough? This is actually more technical question where the judgment of the programmers should be taken seriously. And also, this is a more general issue that maybe should be put in a separate WD:RFC...--Šlomo (talk) 13:19, 21 May 2013 (UTC)

Keep -- If this was deleted, it would affect so many items, it isn't even funny. I agree with Secretlondon, there is a distinction between the two properties. So why delete this one? T C N7JM 13:04, 21 May 2013 (UTC)
- Because: All the information given by the statement A located in the administrative territorial entity (P131): B can also be described (and more accurately so) by the statements A part of (P361) B; B instance of (P31) administrative unit (or a subdivision of that, which is more accurate). P131 is a mixing of a relation between two items and a characteristic of the latter item itself, which should never be done at all in my opinion. Therefore:
- Delete —★PοωερZ_{_talk} 16:11, 21 May 2013 (UTC)
This is a difficult one. This property is also used for cases like Tne Empire State Building is located in New York. Can we use original language of film or TV show (P364) for that ? That seems to comply with the guidelines in http://www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole/ (link provided in the property documentation). Yet I am not positive that it would be an optimal solution. I tend to think we need a way to say "located in" that would use the most precise item available. either trough a new property or through rescoping located in the administrative territorial entity (P131) or location (P276)). Another solution would be a fully automated system based on coordinates, but I doubt we will get there anytime soon. --Zolo (talk) 16:37, 21 May 2013 (UTC)
- It should be located in: Manhattan; located in New York is redundant to that. I can't think of any case when part of (P361) isn't enough to define the type of being part of when you check what the linked items actually are. The Empire State Building is a building, Manhattan is an administrative unit, therefore it is clear that part of means located in in this case, I'd say. Or can someone point me to an example this is not the case? —★PοωερZ_{_talk} 16:57, 21 May 2013 (UTC)
  - The only problem I can think of, is if the administrative unit isn't geographic. I have some of those problems when I try to edit about Sweden County Counsils. They only exist inside healthcenters and hospitals. It's not completly true, but that is the best way I can describe them. -- Lavallen (block) 20:10, 21 May 2013 (UTC)

Can you give an example item? Danrok (talk) 23:07, 21 May 2013 (UTC)

Halland County Council (Q3231536) give me some serious problems. I cannot say that Kungsbacka Municipality (Q499380) has any relation to the County counsil. Still, any hospital or healthcenter geographicly located in Kungsbacka Municipality (Q499380) is a part of, or have a relation to Halland County Council (Q3231536), but almost nothing else. (Also private hospitals normally have a relation to the county counsil.)

And, I have to, in some way, explain how Halland County Council (Q3231536) is related to Q10718442, and the only possible way to do that is to explain that the citizens in Kungsbacka Municipality (Q499380) and two other municipalities are concerned while the other have no relation to that organisation. The citizens in Kungsbacka Municipality (Q499380) are at the same time citizens in Halland County Council (Q3231536), but only the people. The geography in the area is not related to the County counsil. The geography is related to Halland County (Q103691), not to the County counsil. The County counsil and the County are two different organisations. There can be more than one County counsil in every County, but at the moment, there isn't. The County counsil can be consolidated into a Municipality, it has happend frequently in history, and at the moment it is in Gotland Municipality (Q374794). -- Lavallen (block) 08:46, 22 May 2013 (UTC)

part of and is in have different meanings, and the meaning of each can change according to context. For example, a slice of pizza is a part of the pizza, but is not in the pizza. On the other hand, you can say that the City of Westminster is in London and a part of London. Danrok (talk) 23:07, 21 May 2013 (UTC)

Maybe in English, but I am not so sure that it always looks the same after a translation. Prepositions like in/on/at/for/of etc are always translated as a part of a sentence, not word by word. I guess that is a part of the confusion here. "Located in an administrative unit", sounds when I tranlate it word by word into Swedish as if something is located in the office of the Mayor. -- Lavallen (block) 08:57, 22 May 2013 (UTC)

These difficulties of translation seem to me to be a very good reason for keeping more specific properties like P131, and avoiding general ones like "is a" or "part of". The latter are much more likely to cause linguistic confusion, or at least require awkward/lengthy translations.

Literal transciptions are often not good translations. Having said that, I'm a little curious about whether the property's full description (in English) "the item is located on the territory of the following administrative unit" also transcribes just as awkwardly into Swedish. I'm guessing it should be a bit clearer. --Avenue (talk) 01:16, 24 May 2013 (UTC)

Replace "administrative" with "geographic" and things would be much more easy! -- Lavallen (block) 19:50, 24 May 2013 (UTC)

I know this is a bit of a crazy, useless comment, and I'm sorry, but if this one is deleted, there better be a way to quickly replace all of them with the correct property. T C N7JM 00:55, 22 May 2013 (UTC)
- A script can easily be written to fix everything if required. Legoktm (talk) 21:21, 22 May 2013 (UTC)
  - Yes, the problems will not occur here, it's in Wikipedia this will be a problem. -- Lavallen (block) 11:48, 23 May 2013 (UTC)

One potential problem I see with using "part of" is that the meaning may not be entirely clear. For instance Louvre Museum (Q19675) and Hauteville House (Q1591410) are both arguably "part of" Paris. The former because is is located in Paris, and the second because it managed by the city of Paris. Maybe "part of" is not the best property for the second case, but that may be a bit error-prone. --Zolo (talk) 11:41, 24 May 2013 (UTC)

Hauteville House (Q1591410) is owned by (P127) (and therefore also administrated by) the City of Paris (Q90), but it located in the administrative territorial entity (P131) of Saint Peter Port (Q174262). —★PοωερZ_{_talk} 11:48, 24 May 2013 (UTC)

Yes, but that is assuming properties will be used correctly, and sometimes things can get complicated. Actually, even here, it should probably be both owned by (P127) and operator (P137), as an organization is not always managed by its owner. --Zolo (talk) 12:09, 24 May 2013 (UTC)

Keep without any other viable solution. "Is part of" doesn't work in a lot of cases. --Rs chen 7754 03:33, 27 May 2013 (UTC)
Keep Not redundant. Creek Turnpike is in the administrative unit Creek County, but the turnpike is not "part of" the county. —Scott5114 ↗ [EXACT CHANGE ONLY] 04:36, 27 May 2013 (UTC)
Keep per above. AutomaticStrikeout 14:58, 30 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.

Keep Using located in the administrative territorial entity (P131) instead of part of (P361) clearly signals to editors that this property is for administrative units only.

Using located in the administrative territorial entity (P131) makes the data more reusable for infoboxes - it's easy to distinguish between the administrative unit something is in from other geographical features it may be part of (P361)

If the various types of administrative units are labelled instance of (P31) 'administrative unit' then we will be able to get a bot to check located in the administrative territorial entity (P131) is only used to link to administrative units.

We will also be able to create a hierarchy of administrative units which is not practical if you mix administrative and other geographical units.

Later we can get the devs to add a special 'subproperty' so we can identify located in the administrative territorial entity (P131) as a subproperty of part of (P361). Filceolaire (talk) 07:41, 6 June 2013 (UTC)

Property:P526

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.

Closed per ongoing discussion up the page. --Izno (talk) 23:20, 9 June 2013 (UTC)

P526 (P526): (delete | history | links | entity usage | logs) Too many restricted usage. --Ricordi samoa 22:18, 9 June 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:P576

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 pretty strongly in favor of keeping this, at least for now. Sven Manguard Wha? 05:31, 10 June 2013 (UTC)

Keep I thing when merging, there will be problem with correct label of property - people have dates of birth/death, but clubs or companies date of founding/dissolution. And naming this propery date of birth/founding/creation seems to be very strange. JAn Dudík (talk) 06:27, 30 May 2013 (UTC)
Neutral, linguistic reasons alone are not enough for having two properties, and as far as I can see, date of foundation is logically equivalent to date of birth (some external sources like the BNF conflate them [4]). On the other hand, it may indeed sound odd to use "date of birth" for an organization, and that might scare away a few users. Given that the difference between "foundation" and "birth" seems intuitively clear, that should not be too difficult to maintain two properties. --Zolo (talk) 06:46, 30 May 2013 (UTC)
Keep It just doesn't sound right to say "date of birth/death" for an organization. AutomaticStrikeout 14:50, 30 May 2013 (UTC)
comment: I'm wondering if both sets of these templates couldn't just be done with qualifiers. Have a general "start date" with qualifier "birth" or with "foundation"? Not structured enough? Not easily queried? That would actually associate the foundation of companies with their actual foundation... --Izno (talk) 17:02, 30 May 2013 (UTC)
Comment See: Wikidata:Requests_for_comment/Time_DataType_Properties —★PοωερZ_{_talk} 17:14, 30 May 2013 (UTC)
Comment. If we keep two properties, we have to define the scope of each. To me, the intuitive meaning of "foundation date", and even "creation date" is "date when a conscious agent created it" (and so would not be applicable to natural objects, nor to Universe (Q1)). --Zolo (talk) 15:23, 31 May 2013 (UTC)
I think this guy might like to have a word with you about that. ;P --Izno (talk) 21:52, 2 June 2013 (UTC)

Keep per comments above. Filceolaire (talk) 22:48, 5 June 2013 (UTC)

Strong delete: in the future it will be possible to ajust the label according to the entity type. Nor the conflict of scope is clearly solved. --Ricordi samoa 22:12, 6 June 2013 (UTC)

Keep May be second foundation and second close. With people not be. Sorry English.--Пробегающий (talk) 15:30, 8 June 2013 (UTC)
Keep these two things are related, but not the same. Maybe in the future things will be possible and we might even reconsider, but we live in the now. Multichill (talk) 18:22, 8 June 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:P571

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 pretty strongly in favor of keeping this, at least for now. Sven Manguard Wha? 05:30, 10 June 2013 (UTC)

Keep It just doesn't sound right to say "date of birth/death" for an organization. AutomaticStrikeout 14:51, 30 May 2013 (UTC)
Keep Danrok (talk) 15:03, 30 May 2013 (UTC)
Comment See: Wikidata:Requests_for_comment/Time_DataType_Properties —★PοωερZ_{_talk} 17:14, 30 May 2013 (UTC)
Keep --Pasleim (talk) 18:51, 6 June 2013 (UTC)
Strong delete: in the future it will be possible to ajust the label according to the entity type. We should not keep two separate properties for a mere distinction of entity type. --Ricordi samoa 22:15, 6 June 2013 (UTC)
Keep Discovery not birth.--Пробегающий (talk) 15:33, 8 June 2013 (UTC)
Keep these two things are related, but not the same. Maybe in the future things will be possible and we might even reconsider, but we live in the now. Multichill (talk) 18:23, 8 June 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:P435 and Property:P436

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 these. Sven Manguard Wha? 05:37, 10 June 2013 (UTC)

MusicBrainz work ID (P435): MusicBrainz work ID (P435): (delete | history | links | entity usage | logs | discussion)
MusicBrainz release group ID (P436): MusicBrainz release group ID (P436): (delete | history | links | entity usage | logs | discussion)

Redundant with MusicBrainz artist ID (P434). --Ricordi samoa 03:21, 1 June 2013 (UTC)

It seems that the URL are different, aren't they ? --Zolo (talk) 06:35, 1 June 2013 (UTC)

Yes, they are. See http://musicbrainz.org/doc/MusicBrainz_Identifier#Uniform_Resource_Identifier. Byrial (talk) 07:00, 1 June 2013 (UTC)

But this doesn't mean we need separate properties, does it? --Ricordi samoa 07:09, 1 June 2013 (UTC)

We have actually IMDb ID (P345) for 4 different ID types... --Ricordi samoa 07:12, 1 June 2013 (UTC)

The difference that the two first letters of an IMDb identifier identifies the type of the identifier, where there is no way to determine the type of an MusicBrainz identifier from the identifer without context as the identifier is nothing but a random number in hex encoding. Byrial (talk) 07:22, 1 June 2013 (UTC)

We could easily get the ID type by distinguishing people, songs and release-groups, or even with an apposite qualifier. --Ricordi samoa 07:35, 1 June 2013 (UTC)

That is true that the type of the item will give the necessary context to distinguish the identifiers, provided that mistakes like adding the Work ID of a work to an item for a recording of the work never happens. Byrial (talk) 08:19, 1 June 2013 (UTC)

It would be reasonable to use only one property for all of them (we call them all MusicBrainz IDs after all ourselves). I can see that being a problem if you're auto-constructing the URL though since it depends on it. And you can't really use the data for that directly, since a lot of pages for singles in enwiki are for a song and a music single at the same time and thus have both a work ID and a release group ID. Of course, those should be two different items on WD anyway since they're two different things... but they often won't be, at least for now --Reosarevok (talk) 16:40, 1 June 2013 (UTC)

Qualifiers might be a decent choice for that, now that I read that bit :) --Reosarevok (talk) 16:42, 1 June 2013 (UTC)

Given that they are for different things and hard to tell apart, I'd rather seem them in separate properties. Makes it easier to do consistency checks on it too. -- Docu at 18:07, 2 June 2013 (UTC)

Keep, as long as the urls are not unified, we need to state which one the link belongs to (otherwise it would be buggy and hard to use for external clients). Sure we could use qualifiers, but that is more complicated and I cannot think of any substantial benefit for that. --Zolo (talk) 05:58, 3 June 2013 (UTC)

Keep per Zolo. Multichill (talk) 18:24, 8 June 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:P596

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.

Depreciating and deleting, per consensus here. Sven Manguard Wha? 04:56, 10 June 2013 (UTC)

P596 (P596): (delete | history | links | entity usage | logs) Appears to be redundant to direction (P560), which doesn't restrict direction to compass directions (allowing things like up, down, left, etc.). —Scott5114 ↗ [EXACT CHANGE ONLY] 08:05, 6 June 2013 (UTC)

Delete redundant. --Rs chen 7754 08:30, 6 June 2013 (UTC)
Delete redundant. Snipre (talk) 01:27, 7 June 2013 (UTC)
Delete agreed. See Q19183 for an example of how P:P560 is used in a way that shows P:P596 is completely redundant. Deryck Chan (talk) 16:46, 8 June 2013 (UTC)
Delete - Yup, redundant. T C N7JM 00:36, 10 June 2013 (UTC)

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

I would like to challenge this RfD. I created this property and was not informed that it would be deleted. Nobody that supported the creation of this property has voted here (and were probably also not notified). This is not the way things should be done :(. --Tobias1984 (talk) 15:50, 11 June 2013 (UTC)

Why was this deletion request closed too early? Why wasn't it at least left open until the 17th? Multichill (talk) 19:48, 11 June 2013 (UTC)

I don't consider the closing too early at all. There is no established timeframe for closings; I close them when I see a clear consensus or when I that the conversation has reached a point where consensus would be impossible to reach (at which point I recommend an RfC). I am sorry that you were not informed of the discussion - that probably should have been done. As for reversing the deletion, which is what I'm sure you're asking for even though you haven't gotten around to actually saying as much, if you can present a good argument for why it isn't redundant to direction (P560), I would be more than willing to re-open the discussion. You can post it right here, below my comment. Sven Manguard Wha? 22:25, 11 June 2013 (UTC)

No need to revive the discussion. I can see the overlap of the two properties. My only wish is that relevant people are informed of such a discussion. --Tobias1984 (talk) 09:04, 12 June 2013 (UTC)

Property:P614

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 worry that part of (P361) is being used for too many things and with too few qualifiers to differentiate it's uses, but there's a clear consensus for deletion here. There is also, I should note, no policy or guideline that I am aware of that allows the speedy closure of a property because it is new. If the property should not have been created, as is the case here because there was no discussion for it, the property's age saving it from deletion would be counterproductive. Sven Manguard Wha? 19:12, 10 June 2013 (UTC)

P614 (P614): (delete | history | links | entity usage | logs) Redundant with part of (P361). --Ricordi samoa 22:14, 9 June 2013 (UTC)

Speedy close: this was created just now. -- Docu at 05:44, 10 June 2013 (UTC)

Why did you create this property? There was no discussion on it. This should be a speedy delete, not a speedy close. Mushroom (talk) 18:03, 10 June 2013 (UTC)

Delete. Clearly redundant. Mushroom (talk) 18:03, 10 June 2013 (UTC)
Delete Redundant. Snipre (talk) 18:32, 10 June 2013 (UTC)

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

Can someone tell us what this was? Secretlondon (talk) 19:37, 10 June 2013 (UTC)

See Wikidata:Property_proposal/Archive/8#archipelago_.2F_.2F_archipel --Stevenliuyi (talk) 19:47, 10 June 2013 (UTC)

Wikidata:Properties for deletion/Archive/2013/1

Bulk deletion request

Property:P31 "is a"

"Type of" properties

Property:P435 and Property:P436

Navigation menu

Search