The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
After dragging out for far, far too long, it's clear that there's not a consensus for deleting this. If anything, there's a weak consensus for keeping it. Sven ManguardWha?07:49, 6 September 2013 (UTC)
This one desperately needs to be deleted, not least because of the fact that it is a reciprocal but also because it slows down the rendering of pages like Russia or (I'm sure) the item for the United States. The relation can be inferred for now. --Izno (talk) 01:14, 27 May 2013 (UTC)
Seeing as we're suggesting this one for deletion as a reciprocal of another property currently up for deletion, that one should close as keep immediately. Both should not be up for deletion at the same time. TCN7JM02:15, 27 May 2013 (UTC)
Would just like to suggest in advance the same thing I suggested above for P527: We only use this for cases where there's no separate list of subdivisions, and otherwise we'd instead use a "list of subdivisions" property. But obviously this'll be a moot point if P131 is deleted (in which case my !vote would be to merge this to P527). — PinkAmpers&(Je vous invite à me parler)06:15, 27 May 2013 (UTC)
I thought that Wikidata was created to make it useful in Wikipedia-articles?! Please, tell me how "reciprocal" properties will be fetched in Wikipedia! I can find them with a bot, but as far as I can see, not from Wikipedia. -- Lavallen (block) 07:32, 27 May 2013 (UTC)
The main purpose of Wikidata was and is to help Wikipedia, but it also lives stand-alone. So we should not sacrifice scalability (which only a database can offer) just for the sake of infoboxes. In few months Wikipedia (and all sisters) should have much more power with data. --Ricordisamoa07:39, 27 May 2013 (UTC)
"In few months Wikipedia ... should have much more power with data." - How? I am starting to belive it was a mistake to let us start to edit in this project before all mayor tools were available. As long as we do not see those tools and the benefits they have, it is impossible for me to see the benefit for Wikipedia (and sisters). And without that benefit, my interest in contributing here is nill.
I completely agree. Phase II started way too early, but that's how it is now and we have to deal with it. That doesn't change it's a bad idea to postpone our work on data structure, because if a system consolidates it becomes hard to overhaul, even if it is inconsistent and redundant and therefore less useful. —★PοωερZtalk11:27, 27 May 2013 (UTC)
I do not see how this one is redundant even if P131 is kept. There is no easy way to get this info on Wikidata and add it to Wikipedia articles.--Ymblanter (talk) 09:51, 27 May 2013 (UTC)
Keep How else can I say that Q191091 have subdivisions q628280, q833856 and q757240? I am not against merging with Property:P527, if will be systematically merged all "almost similar" properties. And yes, if there exists separate "list of municipalities in distric XYZ", it sholud be linked instead of all members. JAn Dudík (talk) 12:41, 27 May 2013 (UTC)
I have to say, I'd be against merging this with P527. "Consists of" can have a much wider meaning. For example, South Dakota consists of about 830,000 residents, but subdivides into 66 counties, all of which should contain "is in the administrative unit" → "South Dakota". TCN7JM17:10, 27 May 2013 (UTC)
Keep For now it's impossible to have all administrative divisions in a item without this property. I can change my vote it this possibility will be added. --ValterVB (talk) 14:51, 9 August 2013 (UTC)
KeepIt is not redundand, remember this project is primary made for bot and there is the need to scroll fluency up and down tree of data Rippitippi (talk) 23:09, 14 August 2013 (UTC)
Keep I agree with Holger1959, this property is needed. If you want you may fuse has part(s) (P527) with this property or eliminate, but this property must stay. - Sarilho1 (talk) 14:41, 18 August 2013 (UTC)Comment I was reconsidering my vote: as Holger1959 said, located in the administrative territorial entity (P131) and this property are not reciprocal (which I agree), so this property is completely useless. The only was we can describe not just actual administrative subdivisions, but also historic subdivisions (using time qualifiers). If one articles contains (for example) 100 administrative divisions which it subdivides, more 300 other historic subdivisions, the item would be huge and confusing. I prefer don't vote for now, because of this. - Sarilho1 (talk) 14:57, 18 August 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.A summary of the conclusions reached follows.
Delete. P288 (P288) is not like other "type of" properties as it is a super class of the ship types and is redundant as we can follow vessel class (P289) to the level above to see what watercraft type type a ship class is. Here we are defining a hierarchy of items so using a consistent property like subclass of (P279) makes sense. As it is only needs to be used on ship classes, not on ships, therefore it is used on many fewer items than vessel class (P289) so making it easier to use is not quite so important.
Esquilo, could you explain your claim that "the diversity of items pointed to by instance of (P31) would be unmaintainable without them"? Could you point me to an example of any other Semantic Web implementation having maintainability problems caused by widespread use rdf:type? Emw (talk) 00:10, 26 June 2013 (UTC)
Pretty much everyone the size of Wikidata without a stringent data model. Wikidata does not have a stringent data model, this page is a living proof of it. Considering DAG, the concept is not usable on Wikidata. Imaging deleting all taxonomical properties (like P71 (P71), P74 (P74), P77 (P77) etc) and using only instance of (P31). Such data model would be useless on other Wikimedia projects. P288 (P288) and vessel class (P289) fulfills the same purpose for ships as P71 (P71), P74 (P74) do for animals. /Esquilo (talk) 08:34, 27 June 2013 (UTC)
If the same information can be readily available using another, not yet implemented feature, it is great. But until "queries" are implemented and P288 (P288) is replaced with "queries" in all items, it should be kept. Once "queries" are implemented, we can bring up this discussion again. /Esquilo (talk) 13:46, 27 June 2013 (UTC)
Then you propose a massive amount of work later, just so we can use Wikidata now in Wikipedia. That's a bad idea, start using data in Wikipedia later instead. And all this mess because the devs were so overhasty to start phase II before it was ready... —★PοωερZtalk14:41, 27 June 2013 (UTC)
I agree on the hasty bit, but nevertheless, phase II is live. I am also a bit concerned about the long run usability of Wikidata. Almost every step in the progeress of Wikidata seams to lessen the usability of Wikidata for other projects like Wikipedia by making the access of information more complicated. /Esquilo (talk) 10:49, 1 July 2013 (UTC)
Comment Isn't 7:2 still not enough to finally delete this property? No ones here feels responsible. The whole concept of RfP doesn't work. More than three month for a single RfP request is a shame. --Nightwish62 (talk) 21:16, 3 September 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.A summary of the conclusions reached follows.
Keep. Did he use all those Pseudonyms? If yes then he had 4 pseudonyms and they should appear as pseudonyms. 'Multilingual text' is for translations and is not suitable here - 'Chazon Ish' is not English. If thealternatives listed by Shlomo are transliterations then they should be given in qualifiers - I have proposed some suitable qualifiers properties at Wikidata:Property_proposal/Generic#Transliterations. Filceolaire (talk) 11:27, 20 August 2013 (UTC)
Then the property should be in monolingual text, instead of string. Strings are for language independent values, such as ISBN. --Wylve (talk) 09:37, 25 August 2013 (UTC)
The 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 may work, but the purpose is not exactly the same. Arguably all of these items are a part of Star Wars. There is potentially for going so generic that the data becomes unusable due to vagueness. Danrok (talk) 20:16, 21 June 2013 (UTC)
Wikimania is a series of events, of which Wikimania Hong Kong 2013 is a member, but that is not the only set in which it is included. Attack of the Clones is a member of the Star Wars series of films. Fade to Black is (the last) member of The Sopranos television series. The first member of the series of whole numbers is "0". Not all series are finite, but all are countable, composed of discrete elements in an ordered set. While they may need better documentation, it is not at all clear whether these properties can all serve the same purpose. LeadSongDog (talk) 20:04, 28 June 2013 (UTC)
Keep This property does not work like Property:P361 or Property:P527. Some elements can be part of more than one thing, and such things cannot necessarily be a series. This property is intended to roganize all elements closely related between them beyond a simple conection, which is "part of" means. — ΛΧΣ2122:49, 21 July 2013 (UTC)
Keep Frankly, I'm becoming infuriated by this desire to pare down the number of properties to as small a number as possible, at the cost of clarity, functionality, and ease of use. There is a "series" field in the much used Infobox video game template, and I'm sure it's used in other infoboxes as well. If the point of Wikidata was strictly to record information, without paying attention to how that information is/was intended for use, your proposal might have merit. The fact of the matter though is that part of Wikidata's intended use is to support Wikipedia infoboxes by centralizing the information, field by field, on Wikidata. Every time we yank an existing field in the name of blind efficiency, we make it that much harder for Wikidata to be used constructively. Sven ManguardWha?07:33, 6 September 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Delete The property was added without reaching a consensus. The "status report" on the talk page is miscalculated, there are only 5 voices supporting the property as proposed (and created).
The item datatype is not distinct enough to describe the form of the name to be matched with the described person. A name item can refer to the name in various forms (e.g. en:Katherine (given name)#English). Moreover, the labels in various languages choose one of the possible forms of the name which may or may not be suitable for the described person. There's a big variety in the question which names should be translated and which should be left in the original language (after transcription into the local alphabet eventually); different approaches can be found not only between different languages, but also in one language, depending on time period, life story, profession etc. The example given in the discussion works well with English, but the labels of the item Georg (Q1985538) would tell us that Washington's given name was Juraj (in Slovak), Георгий (in Russian) or ホルヘ (in Japanese. The labels of George Washington (Q23) on the other hand use the form George (in Slovak), Джордж (in Russian) and ジョージ (in Japanese). The other way round, Božena Němcová would be awarded with the given name Bożena in English and the actual Czech president gets a nice 19th century styled digraphed form Milosz.
The property is essentially correct, but it doesn't tell anything more than "One of the given names of George Washington (Q23) is some form of the name Georg (Q1985538)". That's virtually useless for Wikipedia. Theoretically we could use it to make a wikilink to the article about the name, but still we don't know what should be written in the description of the link.
Therefore I suggest deleting the property and creating it as MultilingualText datatype (when available).--Shlomo (talk) 16:39, 5 August 2013 (UTC)
Keep recreating or changing to MultilingualText datatype doesn't seem like a good reason to delete this now. If it is to be MultilingualText, surely it should be kept until that happens? Danrok (talk) 14:26, 2 September 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Delete The property was created after a tight vote (in fact 10:9, not 13:4 as stated on the talk page...) and with a lot of important remarks left unanswered.
Like the #Property:P735, the item datatype doesn't tell us clear enough, which form of the name the person uses/used. AFAIK all the Slavonic languages (and probably some other languages too) differentiate between the male and female form of the family name, some of them have even several female forms. The articles on Wikipedia (and consequently the items on Wikidata) are generally (and IMHO correctly) assigned to the name covering all it's variants - sometimes (but not always) differentiating between various spellings, like Švarc (Q10502447), Schwarz (Q20267) and Schwartz (Q2253338) and exceptionally differentiating between gender variants, like Novak (Q729388) and Nováková (Q3345550).
The property is essentially correct, but it doesn't tell anything more than "One of the family names of Božena Němcová (Q157970) is some form of the name Němec (Q1977134)". That's virtually useless for Wikipedia. Theoretically we could use it to make a wikilink to the article about the name, but still we don't know what should be written in the description of the link.
Therefore I suggest deleting the property and creating it as MultilingualText datatype (when available).--Shlomo (talk) 17:19, 5 August 2013 (UTC)
Keep Good property, allows to link article about surname and surname owners. Gender is not problem at least in Russian. This is only forms of one surname. For example Kuznetsov (Q4245091) is about both male (Кузнецов) and female (Кузнецова) forms. — Ivan A. Krestinin (talk) 18:10, 5 August 2013 (UTC)
That's what I'm saying, the item is about both Кузнецов and Кузнецова, but is only labeled as Кузнецов. If you use this property in an article about Svetlana Kuznetsova (Q192064), you will get the male form of the name as a result... (together with the correct link, that's right).--Shlomo (talk) 18:24, 5 August 2013 (UTC)
There. Fixed. I renamed the items as 'Němec/Němcová' and 'Kuznetsov / Kuznetsova' so you can use P734 to link to this and it is right whether the subject is a man or a woman. Filceolaire (talk) 19:51, 5 August 2013 (UTC)
You should add also 'Nemec', 'Nemcova' and 'Nimets' (as for now). But could a statement like this be used in a Wikipedia infobox (or elsewhere)?--Shlomo (talk) 20:40, 5 August 2013 (UTC)
It surely will. But the MultilingualText datatype will enable you to control the search better. The Item gives you a set of all people who use any form of the name. E.g. if you'll be looking for Peter (Q2793400), you will get everybody called "Петр", but also everybody called Peter, Petr, Pierre, Pedro, Petur, Petelo, Pit, Pêr etc. Is this what you want? If there will be a property with the exact form of the name, you can design the query to find just the form(s) of the name you want.--Shlomo (talk) 23:38, 5 August 2013 (UTC)
Why would an item covering both Němec and Němcová be used for a person who has one of those names? Shouldn't a more specific item be used? Also, being useless for Wikipedia doesn't mean we should delete the property. Wikipedia is not the sole use-case for the free knowledge base. --Yair rand (talk) 21:57, 5 August 2013 (UTC)
The same reason, why would an item covering both Obama and Obamová be used for a person who has on of those names. These are not two names, just two forms of the same name. In some languages. While other languages may use only one form. Or three forms.
Your other point sounds stronger. We don't have to delete a property which is essentially correct just because we don't have any use for it in the Wikipedia. We can have one family name property as an item datatype and another one as a multilingual text. Actually, we can use them together, one as a qualifier of the other.
I'm just afraid of sourcing the item-typed name-properties. We surely can find a source that assignes George Washington (Q23) to the given name "George". But is it enough to assign him to the item Q1985538 which is defined by 40 forms of the name, if we cannot bring a source for all of them? And especially, if some of them clearly don't match with the person (but can't be separeted from the name-item)? The problem is more obvious for the given names, but is essentially the same for the family names.--Shlomo (talk) 23:38, 5 August 2013 (UTC)
No, this is a bad example. You can stultify any property (good or bad) by choosing unappropriate value for it. If you use the "correct" ones, you'll get Georg (Q1985538)Bush (Q224168) - which is bad enough, if you change language e.g. to Slovak or Finnish...--Shlomo (talk) 06:27, 6 August 2013 (UTC)
Well done. Please change (or remove) the corresponding labels in cases like this, if you can. There's a lot of mismatched names like these and I'm afraid not all of them can be corrected. I'm happy though that a discussion over these properties brings some improvement in this field ;)--Shlomo (talk) 21:40, 6 August 2013 (UTC)
Comment Uh, I can't remember. What was the reason for Wikidata again? Ahhh, query data. If we aren't able to query a person which surname is 'XYZ', then we should close Wikidata immediately. --Nightwish62 (talk) 10:29, 20 August 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
I'm thinking of an RfC for language taxonomy representation. There are a fair number of issues to sort out around how exactly to relate languages to families and families to other families (assuming we make the distinction). KleptomaniacViolet (talk) 16:51, 3 September 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Kept for now, premature nomination. Discussion can be reopened when Phase 1 for Commons has started and we see how it works. -- Lavallen (talk) 13:55, 17 September 2013 (UTC)
hold your horses, we still know very little of how it will work or how it will be used! A 1:1-match between Wikipedia and and Commons looks very very far away. -- Lavallentalk(block) 10:39, 9 September 2013 (UTC)
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.
datatype: I did not know about "monolingual text" when I created this property, and I still do not know exactly how it will be different from string, does anyone know about that ? I suppose we have the same isse with P357 (P357).
discussion: I think I had proposed it, but there were no comments before I created it.
use: it has at least two:
make sure that the claim is really made in the purported source. I have seen countless examples in Wikipedia where it is not the case.
qualify the claim, when there are important things that cannot be adequately be said in pure database language. For instance, it is hard to say who is depicted in Venus de Milo (Q151952), and I think the quote provided in Mérimée ID (P380) helps with that.
Copyright: that is the main problem imo. I think that short quotes are legally acceptable in just about every circumstance, but I suppose that does not technically remove the copyright. Note that the situation seems to be the same in Wikipedias, as the quoted texts are not CC-BY-SA either.--Zolo (talk) 09:01, 7 June 2013 (UTC)
Strongly oppose to deletion: there is right to quote and fair use, both of them allow quotations, as long as it is bona fide. Instead of this proposal for deletion, what about starting a debate about how to use it and where are its limits? --Micru (talk) 20:23, 10 June 2013 (UTC)
Citing fair use in defense of this property seems invalid on its face. As the site's footer notes, Wikidata's "structured data from the main and property namespace is available under the Creative Commons CC0 License". In other words, by putting quotes into a Wikidata claim (a subject-predicate-object, a unit of structured data), we would implicitly be asserting that those quotes are in the public domain. Subjects to which fair use applies are copyrightable; they are not in the public domain. A proper defense of this property would argue that quotes are not copyrightable. The article Copyright Protection for Short Phrases from the Stanford Copyright and Fair Use website seems like it could provide some guidance on this. Emw (talk) 01:22, 13 June 2013 (UTC)
Any comment on this? Copyright issues are this property's main problem, and it seems like that's not being addressed. Emw (talk) 14:36, 7 September 2013 (UTC)
I have quoted this document many many times on Wikipedia, I have even uploaded it to Commons, since it is from early 1900. Do you have any problems with that I will copy small parts from this document here on Wikidata into this property? -- Lavallentalk(block) 16:38, 7 September 2013 (UTC)
I think so, and so for P357 (P357) I would say, and really I do not know what we should do about that. I would guess go for an approximate datatype until a better one is available. We can do without P387 for a while, but deleting P387 would be really problematic, so I suppose we will need to clean things up once monolingual texts are available in any case. --Zolo (talk) 16:33, 11 June 2013 (UTC)
Delete but weak. if we provide the data of the source we don't need the quote, each person can find the information in the source. Quote is useful only when the statement in the source is not clear or when you want to discuss the qoute itself in a text. Snipre (talk) 13:12, 27 August 2013 (UTC)
If it's free or not depends on where you live. Copyright-laws do not look the same everywhere. There are thousands of pictures on Commons I wouldn't use if I would publish a book, or even use on Wikipedia. -- Lavallentalk(block) 06:18, 6 September 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Consensus is for deleting P719 (notable incident). I've changed the English language label for P793 to better reflect the property's intended purpose, with the old name as an alias and P719 as an alias. Sven ManguardWha?03:21, 21 September 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
I'm not sure of the wisdom of this path of stuffing more and more information into 'instance of' rather than using more specific properties, but consensus is clear for deletion here. Sven ManguardWha?03:44, 21 September 2013 (UTC)
P302 (P302): (delete | history | links | entity usage | logs)
Given its currently low use, and its duplication of the subclass of (P279) and instance of (P31) chain, I am proposing this property for deletion. I would replace every one of its uses today but were it for the fact that people get really unhappy when talking about a type property. This property also suffers the same problems as the notion of a main type, which is another reason to delete it. --Izno (talk) 18:53, 14 September 2013 (UTC).
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.
image (P18): (delete | history | links | entity usage | logs | discussion)
Wikidata is all about specific data for a certain item. But there is no specific image for any topic, rather there is a potentially unlimited number of ways you can illustrate an item. On first impulse you might say: why, it's easy to define the portrait of a person. But the Commons category of Albert Einstein shows a wide range of images from the different stages of his life. Even if you would try to limit the selection to the "latest" image or the image at the "time of his greatest success" there would still be a high number of candidates and it would be an arbitrary choice. Or if this property would require the most "famous" picture (a questionable distinction) with Einstein it would rather be the famous "tongue" image. But this is no appropriate photography for an encyclopedic biography, not as the image "defining" the topic anyway.
And although many articles deal with people's biographies, most articles have topics that are even more difficult to illustrate. What is a city? The sign at the city limits? A satellite image? "The one" most "famous" sight? Even worse are abstract concepts like "happiness". Take the image of choice for Q8: Is this an image of "happiness"? No, it's the picture of a woman kissing a baby. Of course many people might regard this as a typical moment of happiness, many others won't. It is a question of individual experiences, of different cultures, and even of different languages. The German article linked there is "Glück", but this word also translates as "luck" or "chance". So a German might consider a four-leaf clover, a horseshoe, dice or a Roulette wheel a good illustration for Q8. Neither would be a good illustration for "happiness" though. But people already start to link the Wikidata picture P18 in the articles without having control over the content. Wikidata is a central database that the different Wikipedias can link to, at least to the reliable data and properties. But images are not reliable and it would be difficult to rule out images while allowing all other data. And what good would the image be, if you cannot link it?
So my reasoning is: there is no way to find or define "the one" image that illustrates a Wikidata item. The choice will always be an arbitrary one and not everybody and not every Wikipedia will agree with the individual choices. This is not a typical property for Wikidata and there can be no general rules to define the one image that should be the Wikidata illustration. The only appropriate way to deal with this problem is to give the link to the Commons category and leave the user the choice of the "right" image for the article in his or her Wikipedia. Accordingly the property P18 should be deleted. -- HvW (talk) 09:53, 16 September 2013 (UTC)
Keep I agree that the prefered image is the article-editors choise, but in some cases is image (P18) a good property, for example in art-related items. I have myself used this property in items related to coat of arms (P237), where the alternatives in the categories often are few. -- Lavallen (talk) 11:07, 16 September 2013 (UTC)
Even if you could define "the one" coat of arms image for the whole WP (CoA, Flags etc. can change over time, files can have different colours, sizes, resolutions, and so on), a better solution would be a specific property for all WP standard files. You can't ignore all the other problems for almost all of the other items just because you think it works in some singular cases. -- HvW (talk) 12:00, 16 September 2013 (UTC)
It's wrong to add sex or gender (P21) in random items too, but I do not propose it to be deleted! If the CoA change over time, we can add qualifiers for it or create new items, since change of CoA often is a consquence of some other changes, like changes from Town to City or to Municipality or anything else... Such things happend a lot in the 1970's where I live.
I fully agree that the use of P18 in many items have to be reviewed, and I will not recomend the use of this property in random templates on Wikipedia. -- Lavallen (talk) 12:54, 16 September 2013 (UTC)
You don't seem to understand the problem. It's not the silly "it can be used wrong so delete it" argument. You can decide whether male / female is right or applicable. You can not decide, what image is the right one. As long as there is a general property Image for all items you can choose any image you like that makes any sense and nobody can tell why it shouldn't be this image or why there should be no image at all. You link your CoA image, somebody else replaces it with a file twice the size, the next one found an image from an old book with darker colours. Wikidata properties have a limited range of values, images have unlimited variations, even if you would think there is only "the one" coat of arms. You can define images of a certain resolution, size and file format as standard images e. g. for national flags. Then you can create a property for flag or state articles to include these images. But it is obvious that there can be no standard for almost the whole rest of the world. That is why this "general" property does make no sense. -- HvW (talk) 13:54, 16 September 2013 (UTC)
We can decide that this and that "range of items" is not in "the range" for any property, just like we can decide if mythical items and/or fictional items and/or items about groups of humans are supposed to use P21 or not. In the end is it the template-designers in the client who choose to use a property or not. From my point of view, P18 is maybe the only media-file-property we need. -- Lavallen (talk) 14:29, 16 September 2013 (UTC)
No, you can't decide anything about a "range". No more than about "the one" image. The different examples should have made this clear. In a way you got the point. If anybody uses this property it's their own fault. -- HvW (talk) 21:23, 18 September 2013 (UTC)
"If anybody uses this property it's their own fault." - Well yes, that is true about all properties here, and about every parameter in every template... -- Lavallen (talk) 09:47, 19 September 2013 (UTC)
Keep Part of the reason we have this property is so that infoboxes can be populated with an image via template. In smaller projects where there aren't enough people for it to be feasible for someone to go through each Commons category to find the 'best' image for each subject, they can use the one in the image field. That's a powerful function, and one that people increasingly seem to forget about on this page. Sven ManguardWha?01:05, 17 September 2013 (UTC)
A sledge hammer is a powerful tool, but not of much use if you want to pin a postcard on the wall. You can do so many things with this unspecific property and people do them all at once. And that does not make it powerful but useless for the specific uses you want to put it to. If you want infobox images, create a property "infobox-image" and define exactly what you want there. If you want flags for flag or country articles, create a property "flag-image". But "image" is everything and nothing at the same time. -- HvW (talk) 21:23, 18 September 2013 (UTC)
You can look into how enbarten is used in sv:Modul;Wikidata. If the module has the parameter enbarten=0, then the first file is collected. enbarten=1, gives the second etc... Many other things in the code in this page has not been updated and I give no guarantees that it works today. -- Lavallen (talk) 05:48, 18 September 2013 (UTC)
Question is not about code. It is about algorithm logic: what image the infobox must use? The first? The last? Random? The best (but how to identify the best image)? — Ivan A. Krestinin (talk) 06:41, 18 September 2013 (UTC)
Agree, we have to solve that. I am currently (and maybe for several years from now) working with Swedish Municipalities. The most frequent illustration on svwp is the office-building of the municipal administration. I guess it would be nice if we could create relations to an item about the building and in that item use P18, instead of putting them directly into the municipality-item, which tells very little today about it's relation to the item. -- Lavallen (talk) 07:25, 18 September 2013 (UTC)
Keep. While there may be disagreement as to which is the best image that doesn't mean we can't have any.
Where multiple images are listed we will be able to specify one of these as the preferred image, once the developers have the ranking facility available. Filceolaire (talk) 17:15, 19 September 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Consensus appears to be clearest for deleting Venue and only Venue. Venue will be deleted as soon as all instances of venue are replaced with location. Sven ManguardWha?08:27, 7 September 2013 (UTC)
Keep, these are different relation types. Current ru-label "находится в административной единице" does not allow to use this property for events. — Ivan A. Krestinin (talk) 20:20, 6 August 2013 (UTC)
Actually the current labels for both of these only allow them to be used for events, except in Russian where "venue" doesn't have a label. Filceolaire (talk) 12:34, 2 September 2013 (UTC)
Keep, it isn't redundant to located in the administrative territorial entity (P131) as this property is limited to only administrative units. How will you make e.g. this statement here West German Embassy siege (Q531412)? The German Embassy isn't an administrative unit, so it can't be used. located in/on physical feature (P706)? Doesn't work also. And even if you find (or create) a property for locating non-administrative unit, this would mean we have events spread over two different properties. Not easy or logical when you're searching all events for a specific location, because you've always to considering both properties. --Nightwish62 (talk) 22:57, 6 August 2013 (UTC)
Comment BTW: I'm not an English native speaker, but I believe even in English the term "is in administrative unit" doesn't fit for events. --Nightwish62 (talk) 06:28, 7 August 2013 (UTC)
Comment Thanks for the explanation, I understand your reasoning and have amended my deletion request. But what about P540 (P540)? We still have two properties for what is basically the same concept, i.e. the place where the event was held. In English it doesn't sound quite right to say that the West German Embassy siege (Q531412) was held at a venue, but the Italian label for P540 (P540) is "luogo" (location), the French one is "lieu" (location), the Catalan is "lloc" (location), the Dutch is "locatie" (again, location), so there is much ambiguity. I think we should either delete P766 (P766) and give a broader sense to P540 (P540), or just delete P540 (P540). What do you think? Mushroom (talk) 08:17, 7 August 2013 (UTC)
I think administrative units instances corresponds to geographical locations, but other kind of geographical location (like a mountain) tends to be more geographically stable other time (a mountain does move but in geological times :)). For administrative units, it's not the same : some can disappear, appear, move, ... so the statement will make sense if we also have the date. But I agree, when we give the place of an event, we should give a geographical location (a subclass of geographical location instance). The problem is wether or not we consider if we have an administrative unit and a date, we also have a geographical location. If we consider that as a fact, then we can have one generic property. TomT0m (talk) 09:39, 7 August 2013 (UTC)
Comment Funny. I never saw the venue property. Otherwise I wouldn't created P766. It's a shame the venue property didn't get any "also know aliases". I think venue could work for events. But I can't tell if it's suitable for all kind of events and what's about other languages. It seems 'venue' is used for scheduled events with audience (event = Veranstalltung), not for events which just happens (event also = Ereignis), like a disaster. But it really seems like venue and location/place are very similar or redundant. Even so, we have to decide which to delete and which to remain. --Nightwish62 (talk) 11:07, 7 August 2013 (UTC)
Actually you did good, while I made the deletion proposal too hastily and on bad assumptions. Even if you didn't know about P540 (P540), you created a much better property because it covers all events that don't have a venue and also those that just happen. So my new proposal is to keep P766 (P766) and delete P540 (P540). If you agree, please update your vote accordingly. Mushroom (talk) 15:34, 7 August 2013 (UTC)
One question in general: Will in such cases a bot change all existing 'venue' to 'location'? Is this possible and/or already done before? I think we should have such a bot which can be used to change the property to another property. --Nightwish62 (talk) 16:56, 7 August 2013 (UTC)
"Event location" is fine for the English label. I changed the German label, added some aliases and a description. What would be suitable in French?--Zuphilip (talk) 10:54, 15 August 2013 (UTC)
There is a discussion on the Property_talk:P766 page for "location" about widening this property so it can be used for objects as well as events. Please don't change the labels until this is resolved. Filceolaire (talk) 12:50, 2 September 2013 (UTC)
Keep both. In my opinion, location is preferable for geographic names (states, cities, towns) and venue is preferable for specific buildings/stadiums. AutomaticStrikeout15:50, 16 August 2013 (UTC)
For events and objects in states, cities, towns I think we should use "is in the administrative unit". For events and objects on rivers, mountains, lakeshore etc. we should use "located on geographical feature". For events and objects in stadiums, museums, galleries, streets, villages (where these have items) we should use "location". "Venue" could be used for stadiums and theatres but not for museums and streets so it should (in my opinion) be deleted and "location" used instead. Filceolaire (talk) 12:45, 2 September 2013 (UTC)
Keep We need both properties then the definitions should be modified: we need a property for event and one property for physical place. Some events take place at different places so we need to use sometimes twice the same property and as we have now already two properties we can use both of them. Discussion thereSnipre (talk) 12:58, 1 September 2013 (UTC)
What do you mean by a "property for event" and a "property for physical place"? Both of these properties have "event" as their subject/domain (the page they are used on) and a physical place as their object/range (the page they point to).
If an event takes place in two places then use the same property twice. Please don't use two different properties for the same concept. Filceolaire (talk) 12:23, 2 September 2013 (UTC)
Delete There are some interesting language issues brought up above, but in the two languages that I understand it seems that P540 (P540) is a location, and is thus not needed. Ajraddatz (Talk) 17:05, 2 September 2013 (UTC)
Please, would any admin FINALLY delete 'venue'? Isn't the voting not clear enough? How many discussions and RfC should we start before someone finally act? --Nightwish62 (talk) 17:32, 3 September 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
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.
Country is not identified code. For example there are at least 3 different code systems in Russia (and ex-USSR countries): Экспресс-3, АСУЖТ, ЕСР. Infoboxes must not use unexpected codes because for every code is needed different wikification, name. So management based on different properties is more simple. — Ivan A. Krestinin (talk) 20:36, 22 September 2013 (UTC)
This is precicely why I object to the constant condensing of properties down to an ever smaller number of options. We should have a separate string value property for each code system, one for Экспресс-3, one for АСУЖТ, one for ЕСР, and so on. Yes, there might be 20 or 40 different code systems used worldwide, but I don't see the problem with having a property for each of them. With fourteen million items we're already at the stage where doing anything by hand is foolish, and if we're going to be importing this kind of information using bots, the bots aren't going to care whether it's going into one property or another. It would be foolish to take the airport codes (currently seperate properties for each system) and force them into one system, why should we do it with railway codes? Sven ManguardWha?21:51, 22 September 2013 (UTC)
Ivan:I didn't say 'country' I said 'country code' instance of (P31) can link to items for Экспресс-3, АСУЖТ or ЕСР or any other item for a station code system.
Sven: Using a qualifier which links to an item is not 'linking to an ever smaller number of options'. You can create a new option just by creating an item for that option - much more flexible than having to get a property approved each time. Is it really so much harder for a bot to create a property and a qualifier instead of just a property? While bots will be useful I'm sure that there will still be a place for users fixing wikidata items by hand too - both working together. Filceolaire (talk) 16:33, 23 September 2013 (UTC)
Comment are there stations which have more than one code, drawn from more than one coding system, and existing at the same time? Danrok (talk) 00:58, 30 September 2013 (UTC)
Delete and replace with individual properties for each code system - Just added the IBNR as property proposal. In Europe - even in Germany - there are two different codes common used (UIC and IBNR), so it's not possible to reference a code to a state or something like that with a qualifier. --A.Bernhard (talk) 07:18, 1 October 2013 (UTC)
Comment In addition to my vote: The generic term Station code isn't a term which you can look up. It's artificial and doesn't exist in reality. UIC-Code, IATA or IBNR are coding systems for stations. Compare this to airports, there is no property like "Airport code". It's called IATA airport code (P238) or ICAO airport code (P239). --A.Bernhard (talk) 07:24, 1 October 2013 (UTC)
Keep for generic station numbers with qualifiers. I'm thinking of cases like stations in China, Japan, Korea, and Singapore, with very short station numbers unique only within a particular line or company, but nevertheless is used very commonly on every signs and announcements. Example: en:Namba Station is NK01 for Nankai Railway, and M20, S16, Y15 for the three subway lines. (But if you go to Tokyo, M20 resolves to en:Ochanomizu Station.) In this case, the best option is clearly to use a generic property like this one, with a qualifier to indicate the line. --朝彦/Asahiko (talk) 04:21, 23 October 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
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.
Oppose Everyone can call himself "student of" if he has visited a seminar. A doctoral student is a much higher level and it's a fact. "Student of" you can debate on. It's the same distinction as in en:Template:Infobox scientist: "doctoral_students" and "notable_students". --Kolja21 (talk) 18:28, 17 October 2013 (UTC)
Oppose "студент" and "аспирант" are different roles in Russian learning system. Relations "студент-преподаватель" and "аспирант-научный руководитель" are very different too. — Ivan A. Krestinin (talk) 20:17, 17 October 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
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.
Keep, meaning is not really the same (crossing the Thames is not really the same as being located in the Thames). At the very least, this property is much more precise and would be useful in several infoboxes.(and probably various sorts of queries as well). --Zolo (talk) 20:49, 17 October 2013 (UTC)
Oppose: There is probably a roads-related property this could be merged with. "Located on terrain feature" is not one of those. --Izno (talk) 17:06, 19 October 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The 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.
Keep This has datatype 'item' and links to a page for the surname. This is a very different property and cannot be replaced by 'name'. Filceolaire (talk) 16:27, 8 November 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
I don't agree there is consensus to keep this. I think we should wait till we get consensus on the 'name' discussion above which this is part of. Filceolaire (talk) 17:03, 16 November 2013 (UTC)
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.
Keep, as "parent company" is usually defined by the law, whereas "parent organisation" is ambiguous and can mean anything from owners to a larger group that the item belongs to. --Wylve (talk) 08:50, 21 October 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Consensus is for deleting this. Unfortunately it appears that it will have to be depreciated by hand as there's no one property that all of the current usages (around 1000 items) can be converted to. We can't delete this until it's properly depreciated, so GZWDer, Zolo, and Vogone, care to help?
As for parent club (P831), that will have to be nominated seperately, as it's not clear that everyone is commenting on both, and it would need to be explicit for me to delete it as part of this discussion. Sven ManguardWha?05:01, 15 November 2013 (UTC)
Keep Affiliation is not necessarily the same as being a member. An alliance need not imply control of one entity by another.--Jasper Deng (talk) 08:28, 1 November 2013 (UTC)
Not sure to see what you mean, neither member nor affilication tells anything about the degree of control. --Zolo (talk) 10:35, 1 November 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Several Star Trek characters have "affiliation --> Starfleet". What should we do to replace that? Employer works in that case, but not for Q (the character) where it's "affiliation --> Q Continuum" or Seven of Nine, who should (but doesn't) have "affiliation --> Borg". In all three cases, affiliation is a stand in for 'faction', but in the latter two cases, affiliation denotes fictional race while in the first it denotes occupation. Sven ManguardWha?06:00, 15 November 2013 (UTC)
I know very little about Star Trek, but if I understand correctly. "Q" is the name of both an individual and a species. So to keep it consistent with "instance of human". I would say that Q (individual) is an instance of Q (taxon), and per the discussion of fictional thing that Q (species) is an instance of fictional taxon. As for the Q continuum, it appears to be the place of origin of the Q (species) and I suppose we could have Q (individual): place of birth (P19)Q Continuum (Q2706873) or Q (species): endemic to (P183): Q Continuum (Q2706873)
The name of all induvidials of the Q-species are "Q", also the females. The most known female Q was acting as (male) homo sapiens helmsman on Enterprise and God in the last novell I read. -- Lavallen (talk) 10:20, 15 November 2013 (UTC)
Delete Redundant. —★PοωερZtalk 18:18, 26 May 2013 (UTC)
On hold per TCN7JM. --Stevenliuyi (talk) 03:32, 27 May 2013 (UTC)
Keep How else can I say that Q191091 have subdivisions q628280, q833856 and q757240? I am not against merging with Property:P527, if will be systematically merged all "almost similar" properties. And yes, if there exists separate "list of municipalities in distric XYZ", it sholud be linked instead of all members. JAn Dudík (talk) 12:41, 27 May 2013 (UTC)
Comment I was reconsidering my vote: as Holger1959 said, located in the administrative territorial entity (P131) and this property are not reciprocal (which I agree), so this property is completely useless. The only was we can describe not just actual administrative subdivisions, but also historic subdivisions (using time qualifiers). If one articles contains (for example) 100 administrative divisions which it subdivides, more 300 other historic subdivisions, the item would be huge and confusing. I prefer don't vote for now, because of this. - Sarilho1 (talk) 14:57, 18 August 2013 (UTC)
Not deleted - consensus is clearly in favor of keeping.--Jasper Deng (talk) 19:39, 7 September 2013 (UTC)
speedy-deleted --Ricordisamoa 12:34, 12 September 2013 (UTC)
Strongly oppose to deletion: there is right to quote and fair use, both of them allow quotations, as long as it is bona fide. Instead of this proposal for deletion, what about starting a debate about how to use it and where are its limits? --Micru (talk) 20:23, 10 June 2013 (UTC)
