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.
P526 (P526): (delete | history | links | entity usage | logs)This is the archived proposal. Since you have to look through a microscope to find consensus, this would be enough reason to delete it, but here are my actual reasons: A property located in geographical region makes located on island redundant. This is yet again a mixing of 1) a relation of two items with 2) a property of one of the items itself. All islands have an P31 (instance of) statement island (example). —★PοωερZtalk15:19, 17 May 2013 (UTC).
Delete Would be best handled some other way such as part of (P361). Many things are located on or in other things, so probably best to use a generic property rather than lots of specific ones. Danrok (talk) 23:47, 22 May 2013 (UTC)
How do you think this should be differentiated? "probably best" seems hard use a criterion. -- Docu at 04:00, 23 May 2013 (UTC)
A property called located in geographical feature could cover many situations, so we can say it is located on this island, mountain, in this valley, and so on. Danrok (talk) 14:41, 23 May 2013 (UTC)
Change meaning of P526. Instead first creating located in geographical feature, and then merge it with this property, couldn't we redefine P526 to be located in geographical feature. Byrial (talk) 06:37, 25 May 2013 (UTC)
"geographical feature" is one of the terms used in P107 (P107). If we rename this property, it's likely to become rather messy, combining physical geography and administrative units. -- Docu at 06:57, 25 May 2013 (UTC)
Comment I think we should focus on the question whether identifying the island a place is on is important or not and should be done through a property. If yes, I think P526 is an easy way to enter this information and retrieve it. I don't think the other suggestions address this. -- Docu at 06:57, 25 May 2013 (UTC)
I'm afraid the easy ways are lost since long! I think "The church of Roma" is located in "Roma", "Roma" is located in "Roma Parish", "Roma Parish" is located in "Gotland Municipality", "Gotland Municipality" is located in "Gotland", and "Gotland" is an instance of an "island" will be the natural way to go. A more serious problem is to separate "groups of islands" from "islands". -- Lavallen (block) 07:12, 25 May 2013 (UTC)
The item "Gotland" is a group of islands with one large island and many small. I am not aware of any item about the main island. If there is any, it had to be added above the parish-item, but below the municipality-item. I do not think it is a big problem in this case. You have to be more alert in the Greenland-case, where I think there is an item about the main island, and since all "administrative units" are both about the main island and the surrounding smaller islands, every item about smaller objects have to have a relation to an island-item. I think it will be solved. -- Lavallen (block) 12:13, 25 May 2013 (UTC)
We have to create items for the main islands in these cases. Just checked: There isn't even and item for the Australian mainland, because there are only Wikipedia articles about the surrounding smaller islands and the continent as a whole, which also describes the mainland in detail. This merge is reasonable for an encyclopedia, but not for a database. —★PοωερZtalk14:50, 25 May 2013 (UTC)
Rename to "located on terrain feature" (or create a new property for that and change all items to use it instead of P526) (similar to Danrok's proposal, but more clearly only for natural features). This would be used when the value is a physical terrain feature, such as Lisianski Island (Q661708) or Black Sea (Q166). We would continue to use located in the administrative territorial entity (P131) when the value was a governmental/man-made concept, such as Hawaii (Q782) (the U.S. state). I think a general property is more useful than one limited to islands. For instance, I think I've had a case where I wanted to say it was on/in a body of water. I don't think we have a general property for this yet, but we should take this opportunity to make/repurpose one. part of (P361) is not really suitable, since it's awkward to say e.g. a house on an island is "part of" an island. And it really doesn't work at all if you say an buoy on the Black Sea is "part of" the Black Sea. Superm401 - Talk06:44, 28 May 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.
Closing as no consensus to delete, with no prejudice for or against future renomination pending the outcome of the referenced RFC. --Izno (talk) 22:06, 12 June 2013 (UTC)
Comment I would've voted for delete, but apparently according to the discussion linked above Lua can't currently handle non-flat links to Wikidata items, which means these need to be kept until we can sort out how to generate the entire taxonomical tree on Wikipedia by iteration. Deryck Chan (talk) 23:02, 2 June 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.
Closed - property kept. Discussion below over almost a month failed to gain consensus to delete it, and a previous request along the same lines (Property:P41) establishes a precedent to keep these properties since they are separately required from the suggested replacements below. Ajraddatz (Talk) 23:39, 14 June 2013 (UTC)
On hold There is a mess of merged articles in this subject in the domain I have been working with (Poland and Sweden). P237 cannot be used in this way until the possibility to use redirects as sitelinks starts to work. This because, in many cases counties, provinces, municipalities and cities are using the same coa. And in almost every case I have seen, the article about the coa not only describe one coa, but a group of coa's in a region. But I like the idea of using P237 and P18 in this way. -- Lavallen (block) 19:34, 20 May 2013 (UTC)
On hold A second objection is that this property is use in some projects already, without the possibility to use any information from any other item, than that who is directly related to the article. The developers have to expand the tools available in Lua in the client first so the wikipedia-projects can change their templates. -- Lavallen (block) 19:34, 20 May 2013 (UTC)
I have reverted the use of this property in two templates on Svwp. I am not aware of any other use of this property on that project. Maybe by the use of #property directly in the articles, but that cannot easily be tracked. -- Lavallen (block) 10:27, 23 May 2013 (UTC)
Keep This property is not redundant to coat of arms (P237): It provides an actual coat of arms image, not just the link to an article about the coat of arms. This is more specific than image (P18); more specific properties (such as this one) should always be used instead. The Anonymouse (talk) 16:10, 13 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.
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 Redundant and potentially flooding items with hundreds of claims. (And I can't find any discussion prior to the property's creation other than this.) —★PοωερZtalk02:52, 20 May 2013 (UTC)
Keep Not redundant to P361. P361 is "part of" (e.g. Adam is part of Adam and Eve) P527 is reverse to it: (Adam and Eve have parts Adam and Eve). some talk is here. Machines can easy search in which items is contained P361, but how about people? How can I say,that there is not only item Adam and Eve but also subitems Adam and Eve? JAn Dudík (talk) 08:12, 20 May 2013 (UTC)
All item-type properties could theoretically have "reverse" properties, but when they don't add any new data, there's generally no point. If all items that are "part of" another item are listed in the "consists of" of that other item, what is being added that's useful? --Yair rand (talk) 08:22, 20 May 2013 (UTC)
Don't forget, that Wikidata are primally used by people for searching and adding interlanguage links. When I write article Kain and will be searching on en.wiki, I found only Kain and Abel, but when I go to Wikidata, I can see, that there exists separate Kain and sparate Abel in some languages. And the same for other couples or related terms (Q747083, Q7069444, Q93344) ... or see mixed Q152415. JAn Dudík (talk) 11:33, 20 May 2013 (UTC)
Wikidata is not just for interwiki links. In time that will be just one of its many uses. Wikidata items do not have to have corresponding wikipedia articles. Danrok (talk) 13:04, 20 May 2013 (UTC)
Keep Take a look in Sweden (Q34). I cannot use contains the administrative territorial entity (P150) in this case, since these units are non-administrative, but they are still essential to describe the subject. Maybe I can change from 27 to 3 units and put the other 24 under those three, but I am not sure if the border between them are well-defined. Historicly I have to add such things as Finland to that, but I have to wait until we have a date-datatype. -- Lavallen (block) 19:47, 20 May 2013 (UTC)
Yes, exactly. So how is 527 adding any new data? All the data is just duplicates of the uses of 361, but stored in a different item. --Yair rand (talk) 19:11, 21 May 2013 (UTC)
Sometimes we encourage bidirectional use of properties, but not in this case. Why have a property for father/mother, when there is one for son/doughter? Why encourge the use of P31:capital, when that information is availible in P46? Why have P150, when we have P131? Why have P156, when we have P155? How should I get the information that Q34 is divided in 3 lands, when I do not know where to find these items and maybe not even know they exist? With a robot I can use Whatlinkshere, but I cannot see that this information can be reached somwhere from a template on Wikipedia? Maybe I have to scan every item on Wikidata, but I doubt I have time for that within 10 seconds in a Module. -- Lavallen (block) 19:48, 21 May 2013 (UTC)
Comment This property might be useful. Why? Because we would not claim that an apple is part of cider, but you would say that cider consists of apple. Danrok (talk) 00:01, 23 May 2013 (UTC)
Keep, but limit usage I support that too. It may be redundant, but it is convenient that editors easily can find the consisting parts so they don't begin to add properties which really should be at the parts (like adding sex to items for pairs of people.
Yes. keep for items which consist of more than one other items, and where it is more natural to list the parts in than to have an name for the group
Keep This can help with the Bonnie and Clyde problem - where one wikipedia page corresponds to multiple wikidata items. Filceolaire (talk) 08:12, 6 June 2013 (UTC)
Delete ~ My feeling has been trending toward that these statements which have the potential for hundreds of links on a particular item's page are much less useful than the reverse linkage, and certainly from a maintenance perspective. (They also tend to slow computers trying to process all of the Javascript on a particular page.) --Izno (talk) 20:30, 9 June 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 deletion. I have deleted aunt, but there are several hundred instances of uncle in use, so a bot will need to deal with them. Sven ManguardWha?00:17, 14 June 2013 (UTC)
P29 (P29): (delete | history | links | entity usage | logs)
P29 (uncle) and P139 (aunt) have been causing problems since they were created, mainly because the scopes of an "uncle" and an "aunt", as the English language uses them, are unique to the English language. Other languages struggle to describe these properties, as demonstrated on Property talk:P29 and the highly convoluted property descriptions in other languages (most of them comprise a list of kinship relationships whose union set cover the scope of "uncle", or a literal translation of the sentence "brother of father or mother". Try vi or zh for amusement). Noting that "uncle" and "aunt" are both indirect properties ("uncle" = "father" + "brother" or "mother" + "brother"; "aunt" = "father" + "sister" or "mother" + "sister"), the best solution seems to be to delete P29 and P139, and simply create additional items where necessary. Deryck Chan (talk) 22:42, 2 June 2013 (UTC).
Delete. These properties are clearly redundant, they add complexity without providing any real benefit. Mushroom (talk) 23:05, 2 June 2013 (UTC)
Delete. But you have to define a solution if there is a missing in the relation: if you know the uncle or the aunt but not the father/mother how to do you want to define the relationship ? Snipre (talk) 18:51, 3 June 2013 (UTC)
Comment – I made a list where you can see in how many cases it is possible to deduct the current uses of P29/P139 based on the data in the latest database dump. See User:Byrial/Uncles. Byrial (talk) 07:11, 5 June 2013 (UTC)
Thanks for compiling these data. As the RfC has pointed out, the fact that deleting these properties will create lots of missing links is irrelevant, because the same will be the case for any indirect family relationships, whether they currently have a property or not. My main argument for deletion revolves around the fact that "uncle" and "aunt" are culture-specific definitions; that the property is redundant is a relatively minor point. Deryck Chan (talk) 15:50, 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.
The properties was redundant, but the statements using them was not in 466 out of 603 cases. The statements which is now deleted was not just imports from Wikipedias. 594 statements had no references, 5 was imported from English and German Wikipedias, and 4 used books as references. (see table at Wikidata:Requests_for_permissions/Bot/Dexbot_3)
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.
Explanations: This property was created before the source properties were implemented. This was a way to source some statement. There is currently done by stated in which is widly used to perform that task and in a more general way than property P92. For foundational text we have now Property:P457. Snipre (talk) 15:10, 18 May 2013 (UTC)
I think he meant more general than "foundational text", in the sense that the property can be viewed as meaning "regulated by" like perhaps "US is regulated by the US constitution". I think that is something that we actually need, but it may be a bit tricky, and I am not sure how it should be done. --Zolo (talk) 13:48, 26 May 2013 (UTC)
Again use the source format instead of a property: the original idea of main regulatory text (P92) was to source statement especially with fundamental text of a country/organization. This can be done now with the sourcing properties and the fundamental text of a country/organization can be described by another specific property. And the above example is not convincing because it is so obvious than nobody will claim that information (this is like most Americans live in US): the only way to use main regulatory text (P92) is to source with legal text and this can be done using the existing sourcing properties in a better way with indications of the volume, the page or the author. Snipre (talk) 01:19, 7 June 2013 (UTC)
In this case it is indeed obvious, but there are cases, where it may not be that simple to find the relevant item (not for machines, and not even always for humans). --Zolo (talk) 19:01, 18 June 2013 (UTC)
Keep - Rename the property so it can be used as linking to the constitution of a country (as it is used here Q15180). Replace its usage in sources with stated in. --Tobias1984 (talk) 07:52, 15 June 2013 (UTC)
rename to "main regulatory text" or something like that. We should not simply say "regulated by" because there is is another "regulated by" property for biology. --Zolo (talk) 19:01, 18 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.
Lake infobox 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.
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.
Well, please explain how it can be used instead. We need to fill an infobox field that lists the group of lakes a specific lake is part of. P265 lists just that. -- Docu at 06:12, 26 May 2013 (UTC)
Keep The problem with part of (P361) is that it is so general that our editors can add almost any item after it. Using properties which clearly indicate what type of item they expect makes it easier for editors - the most common answers can even be hinted at in the labels and aliases.
If a property is limited to only use certain types of item then we can can get bots to do sanity checks to flag any references to the 'wrong' type of item.
If an editor adds three different part of (P361) properties to an item then which one will the infobox use? Much better to use more specific properties with names that match those in infoboxes.
I like Byrial's idea of a "group" property, as it would be convenient for infoboxes and with a bit of clever programming, it should allow the same types of sanity checks as "group of lake". I will probably support it, if we can make its meaning sufficiently clear so that casual users do not misuse it. --Zolo (talk) 08:24, 6 June 2013 (UTC
Delete if group is created – The group property is proposed. Another group property (P:P614 - archipelago) is already deleted. I think it and this and others should be replaced by group. Byrial (talk) 07:12, 15 June 2013 (UTC)
Delete We have part of (P361) and the discussion is the same as for instance of/subclass of versus hundreds of specific properties. We have to clear that problem for once: a set of 3 properties for everything or hundreds of specific properties. But no dual systems. Snipre (talk) 12:13, 10 June 2013 (UTC)
Comment – I do not understand this vote: That a lake is one of a group of lakes, doesn't make it located on some terrain feature. Byrial (talk) 07:43, 15 June 2013 (UTC)
Delete I don't understand how this property is supposed to be used if it is not redundant to part of (P361). If a lake is connected to other lakes via watercourses it is part of a lake system, mostly with a common outflow. Example: Drevviken (Q4176489) is a part of Tyresån Lake System (Q4993045). Forsån (Q1361792) is also a part of that lake system, even though it is not a lake, it is a watercourse connecting two lakes of that lake system. /Esquilo (talk) 11:33, 25 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.
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 no consensus for deletion or modification of what exists currently. Discharges into as a general property also doesn't work, through examination of the link below and counterarguments posted. Ajraddatz (Talk) 22:06, 30 June 2013 (UTC)
It is not really nice to go around an accuse User:Мастер теней of such things. I can understand that you bear a grudge against me and do so, but User:Мастер теней has really nothing to do with it. He probably ignores that you need to agree with him before he creates a new property. Otherwise, User:Мастер теней might be creating another property you wont be using .. oh, no, he is creating properties he is using .. -- Docu at 07:43, 20 May 2013 (UTC)
Rivers generally don't discharge, so it would be flows in to. Discharging implies that something empties, like an electric battery.
Mouths of rivers can inflow and outflow according to whether the tide is incoming or outgoing, which means flows in to is not so good either. Danrok (talk) 08:45, 20 May 2013 (UTC)
Delete/merge with P403 – There is no reason to have more than one property to specify an outflow for a water body. Byrial (talk) 19:34, 25 May 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.
Same as above, no consensus for change, though I do recognize that the current system isn't sufficient and that these properties are misused. But, I can't go around deleting them when a viable alternative hasn't been agreed upon. Ajraddatz (Talk) 22:09, 30 June 2013 (UTC)
Keep but redefine to main inflow for any water body: Firstly, there is no reason not to use this property also to specify tributaries to rivers. Secondly, I don't think it would be convenient to specify at items for rivers flowing into lakes or other rivers, if the river is a main inflow for the receiving water body as that is really a property of the receiving water body. And it would anyway be difficult to edit and overview if that information was scattered over many items. I therefore propose to use this property for the main inflows only, i.e. those inflows which should be mentioned in an infobox. If you want a full list of all inflows, query on the merged P201/P403 instead. Byrial (talk) 19:34, 25 May 2013 (UTC)
Thank you. I see some possible problems with this: 1) You can have many discharges into a lake. How can you know which of these are the main inflows? 2) You can also have many discharges into a river. How can you know which of these are the real starting point of the river, and not a tributary or a lake which the river runs through? I would like to hear how the proposed model can answer this. Byrial (talk) 17:55, 25 May 2013 (UTC)
I think the general idea of 23PowerZ's concept is sound. It would probably be ideal for our downstream users once WikiData is complete. Now we just need to find a solution for users who are interested in entering data, reviewing and cross-checking it. -- Docu at 06:21, 26 May 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
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 no real consensus to delete or keep. Arguments of redundancy do carry some weight however properties serve as statements. The different between quantity of unit is the main problem with the property however since this serves as a statement and an ambiguous property does not exist to serve this need, keeping it may be of use. John F. Lewis (talk) 17:06, 28 June 2013 (UTC)
Oppose because we will plenty of redundancy. We will have enough problems with unit symbol when including symbols of specific sicences like crystallography, quatum mechanic,... so the best solution is to start with unit symbol, Unicode symbol and element symbol. Snipre (talk) 17:06, 26 May 2013 (UTC)
V: symbol for vanadium, unit symbol for voltage but voltage is designed by U like uranium in scientific writing. Don't mix everything: unit and symbol are not the same and you can have one symbol and one unit for the same item. If we speak about symbol for voltage (U) and for uranium (U), ok this is a potential for merging, but unit and symbol are different. Another example: temperature symbol is T but unit can be °C or K. Snipre (talk) 18:47, 26 May 2013 (UTC)
So unit is item datatype and symbol is string datatype: you need 2 properties not only one common for everything. Snipre (talk) 12:36, 27 May 2013 (UTC)
But in that case we have to create a property for unit because I am the feeling that when the property unit symbol was created, it was to introduce only unit symbol directly into the quantity item without the need to link the quantity item to the unit item in order to get the unit symbol. We can merge unit and quantity symbol but in that case we need to create a new item datatype property to indicate which unit is used for a quantity. Snipre (talk) 14:38, 27 May 2013 (UTC)
Conclusions: merge symbol in a string property called scientific symbol, create a new item property unit and keep Unicode property alone: scientific symbol for gold is Au but unicode symbol for gold is ☉ , for silver scientific symbol is Ag and unicode symbol is ☽ , for mercury scientific symbol is Hg and iniscode symbol is ☿ Snipre (talk) 14:46, 27 May 2013 (UTC)
Wrong atitude: by deleting without proposing a structure doing the same work of the deleted property you are "destroying" the current system. Now we have a system which not perfect but which is working. Snipre (talk) 17:53, 27 May 2013 (UTC)
Difficult to say which is the correct use of P558 (P558) as only 2 items is using that property. Now we can put in item temperature the symbol of the temperature T using quantity symbol (string) (P416) and the list of units for temperature (°C, K) using P558 (P558). Nobody did it until now but this is possible and not wrong. With the merging it won't be possible. So if we can get the consensus for the need of an item datatype property unit allowing the link between quantities item and theit unit items, the merging can be applied without any regression in the description of quantity items. Snipre (talk) 00:53, 30 May 2013 (UTC)
I think the property name explains somehow. Maybe John F. Lewis could complete the documentation for the property. Obviously after it was listed for deletion, people are discourage to use and document properties. -- Docu at 18:13, 2 June 2013 (UTC)
I do not see how it would make any sense to give the symbol for celsius degree in the item about temperature. If we want a property to state that temperature is measured in celsius degree, we can make a proposal for this, but it does not have anything to do with symbols (and actually, I would probably not support the proposal, as we have already its symmetric, measured physical quantity (P111), that seems a better fit). --Zolo (talk) 19:40, 2 June 2013 (UTC)
Delete. There might be a need to differentiate between different notation systems but that is not what this property does, and as it stands I do not see any use in having two properties. --Zolo (talk) 19:40, 2 June 2013 (UTC)
unit (item): ??? (combinaison of units: kJ/(kg °C))
An item property for unit doesn't allow the description of unit based on combinaison of primary units. The unit property can be avoided if we specifiy in each unit the measured quantity. But there is still a problem to specify combinaison of unit, unless we create an item for each possible unit combinaison.Snipre (talk) 14:02, 13 June 2013 (UTC)
Snipre: We have two options, as you outlined in your comment. We can create an item for every combination of units. This is not that unreasonable a number of units, especially since any combination of units which has been named already has a page. Until we get round to creating those we can simply leave out that property, as here:
And how do I retrieve the symbol "Cp" in a query ? Without a qualifier or a different property the query symbol for heat capacity (Q179388) will give 2 answers without any possibility to distinguish between the symbol and the unit. The only good solution is to create an item unit property but the consequence is to create hundreds of items for the existing units: SI unit, British units, US units,... or multiscale units like Pa, kPa MPa,... Snipre (talk) 12:20, 19 June 2013 (UTC)
@Filceolaire: kJ/kg°C is not the symbol of heat capacity, that's just a false statement.
@Snipre: There are items for most of these. Though there is still a need for units like J/K, that are not actual SI-Units but combinations of these. That's a big problem and I think it's better to discuss this in an RfC, it's also a problem for the number datatype, so we might want to ask the developers about their thoughts on this so far. —★PοωερZtalk17:45, 19 June 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.
It is clear that a large number of people don't like this, but that there is no consensus for deleting it. This mirrors the last discussion. While I could let this drag out for a while longer, I have little doubt that it would matter. For discussions this complex, PfD is not an effective venue for finding a solution. I will be starting a two part RfC myself shortly. Sven ManguardWha?17:42, 30 June 2013 (UTC)
Here's a new reason it should be deleted: It's use cannot be verified. Based on the discussion currently ongoing at WD:Project chat, if we can't verify a claim, then we probably shouldn't make it. In that event then, P107 is tying us to an ontology which has not claimed to represent the million or so items which P107 is now on. I.e., it is not verifiable. On top of this, P107 can only be verified where there is already a GND ID. That fact makes it even useless for the cases where it can be verified, as the type can be gotten from querying the database if the type is even desirable for someone in those cases; its nonuse on en.wiki would indicate that that is not the case for our primary external users.
This is besides its other salient points for deletion, which are numerous and continuing to cause us problems in other ways. We should cease pretending like this is a good property. I was planning to start yet another RFC on it, but this seems opportune. /shrug --Izno (talk) 22:16, 17 June 2013 (UTC)
That's kind of irrelevant to me. Each property should be able to stand with or without another to replace it. We can discuss the replace property after-the-fact IMO. That said, Zolo's outline on the below referenced talk page seems sensible and easy-to-use. --Izno (talk) 20:46, 21 June 2013 (UTC)
You seem to have a mistaken assumption Rschen. There's no reason to believe that this property would be deleted before it could be replaced by another property. The data is unlikely to go anywhere. As I said earlier, Zolo's proposal on the referenced page is a suitable candidate to replace most uses of this property. --Izno (talk) 02:09, 22 June 2013 (UTC)
Delete – I looked at the archived discussion and saw many strong arguments for deletion, which in my opinion was not adequately answered by those who voted keep. P107 is by some supposed to give a high level classification system, but it doesn't work. I have worked a lot with the database dumps for Wikidata, and it is hard to use P107 for anything useful. Pr. 2013-06-10 there was 1221158 items with GND type person, but I cannot tell how many reel persons there is. If we dropped that useless GND type property and instead used the resources to instance of (P31) and subclass of (P279) and other properties giving reel information, I could tell much more about the items. Byrial (talk) 23:15, 17 June 2013 (UTC)
Keep - I think that before we can even begin to discuss the deletion of this property we need a really good alternative in place. As long as there is no consensus how to separate fictional people from real ones for example. --Tobias1984 (talk) 06:42, 18 June 2013 (UTC)
Question – I do not quite understand. P107 can not be used to separate fictional people from real ones, so what is the connection between this property and the missing consensus about fictional people? Byrial (talk) 06:52, 18 June 2013 (UTC)
General classification is necessary especially in query to be able to restrict the search in a medium extend. I agree with you about GND classification and its small number of possibilities but we need this kind of classification. The only good way to delete GND property is to propose first another classification: don't delete an bad system with nothing but with a proposition of a better system. Snipre (talk) 08:05, 18 June 2013 (UTC)
I have started a table to see what are the possible use, shortcomings and alternatives for the current GND values --Zolo (talk) 09:15, 18 June 2013 (UTC):
The first is irrelevant. The second makes no sense; why should there be a skeleton? If you look into the previous discussion, there are strong reasons not to use anything resembling a main type. (And discussed elsewhere!) --Izno (talk) 20:46, 21 June 2013 (UTC)
Delete Replace P107 (P107) with 'instance of GND Main type' ONLY for the 7 pages which describe the GND main types. For all the other pages use instance of (and all it's 'type of' synonyms) to assign basic items to hundreds of classes then use 'subclass of' to link the classes together in a hierarchy which may (or may not) eventually end in these seven classes. --Filceolaire (talk) 22:06, 21 June 2013 (UTC)
Keep The classification can certainly be improved, but I do not see any advantage in deleting it. It remains an effective way to quickly define an item. Alexander Doria (talk) 10:21, 23 June 2013 (UTC)
"an effective way to quickly define an item" is not what we are here to do. Beyond that, there are the many issues with the property that continue to go unanswered. See also Zolo's proposal above. --Izno (talk) 23:50, 26 June 2013 (UTC)
Delete None of the several major problems with P107 that I laid out in P107's previous nomination for deletion have been resolved. P31 and P279 are much better alternatives to P107: they're W3C recommendations for the Semantic Web that do what P107 does, but more robustly and without the major problems described in the linked discussion. Emw (talk) 23:36, 26 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.
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 is clearly reached. I'm writing a bot script for migration, and I'm going to delete the property once orphan. --Ricordisamoa22:23, 6 June 2013 (UTC)
As duscussed on Property talk:P100, the restriction to "state" does not make much sense. It does not even allow to have the full list of members of the World Trade Organisation or the World Health Organisation. This property could be broadened to "members" but many organizations have thousands of members. This kind of one to many relation can be emulated by querying the neater symmetrical member of (P463) property. --Zolo (talk) 10:57, 19 May 2013 (UTC)
Support on the condition that the domain of P463 is changed, so it is not just persons, but also organisations, countries and subdivisions of countries, and maybe more (What else can be a member?) Byrial (talk) 13:14, 19 May 2013 (UTC)
This property seems to be for a fairly finite group of organizations which all have the same set of members to pick from. It seems easier to edit membership for these on the item of the organization than on items for each individual member state. Bots can than replicate that to the item for the member state. -- Docu at 19:57, 19 May 2013 (UTC)
It's a personal question: we are attempting to determine what you mean with "viable" in terms of building a database. -- Docu at 07:23, 20 May 2013 (UTC)
Support. This item is defined the wrong way round - it should be "is member [state/country/whatever] of". In a sense Property:P361 already covers this so this one is redundant. Deryck Chan (talk) 22:30, 2 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.
Comment: Since the deletion has been agreed upon, I won't oppose it. I'd like to point out a few things though: First, P100 is obviously older than P463, at that time there wasn't a property to use. Second, I don't really see why it's the wrong way, it's just the opposite way of P463 (there's also Property:P150 as the opposite of Property:P131, though I see that's also to be deleted). Third, the United Nations item has all or most members so I don't see why WTO and WHO wouldn't allow to have all members. SPQRobin (talk) 20:04, 12 June 2013 (UTC)
That was nothing against you :). I think there were two completely separate issues with this property.
that it is simpler to use "member of" than "has members", though both are logically equivalent.
that the "state" restriction makes things unnecessarily hard to handle. For instance, the European Union is a member of the WTO, but it is not a state. --Zolo (talk) 19:22, 18 June 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.
Comment No really. If there is a more specific property, such properties should be used, instead of the generic "P31/is a". Property 289 makes it easier to enter/cross-check and retrieve the information. -- Docu at 03:26, 29 May 2013 (UTC)
"Class" appears to be a commonly used concept a relatively well-defined concept, so I do am not as sure about getting rid of them as I am for "type of" properties, but still, I see that en:Template:Infobox_ship_characteristics mixes class with other info about the type of ship, which seems to suggest that this is not so convenient to use a separate "class" property. --Zolo (talk) 14:46, 29 May 2013 (UTC)
Is there an actual sample of infoboxes that work? I suppose it reads to write that in theory, one property is sufficient for WikiData. In reality, infboxes are gradually built and complied and need cross-checking. I understand that this may be new to some of the participants of this project. -- Docu at 19:50, 30 May 2013 (UTC)
It's only a drop-in replacement if there's no other possible thing it can be an instance of. In some cases, that is not true. For example, Eclipse (Q778649) is an individual ship (not a member of a ship class). It has instance of (P31) => ship (Q11446) and P288 (P288) => luxury yacht (Q443802). Most likely, the first should be dropped (too general), and the second changed to instance of. However, that means you can't simply convert all P31 to 'ship class' in a template. You need to be more careful, as in my algorithm above that checks against ship class (Q559026). Superm401 - Talk05:46, 3 June 2013 (UTC)
Delete Having a multitude of domain-specific 'type of' properties is redundant: the W3C-based instance of (P31) and subclass of (P279) properties are sufficient to specify canonical type information for all items. The notion that we should use more specific 'type of' properties when such properties are available is exactly opposite of how we should approach classification. It sets the precedent for an explosion of such superfluous 'type of' properties, and fractures Wikidata into a less coherent structure for all knowledge. Emw (talk) 23:39, 29 May 2013 (UTC)
This isn't actually a valid reason for deletion. w3 schemes are not part of Wikidata. We currently don't have any pratical use cases for instance of (P31) and subclass of (P279), while we do have working infoboxes with this field. If one needs to view this property combined with others as one, this can be done further downstream. -- Docu at 19:50, 30 May 2013 (UTC) (edited)
W3C recommendations for the Semantic Web are an important part of Wikidata. For example, Wikidata will be exportable in RDF (see Wikidata requirement P2.6). The wider connection between Wikidata's design of statements -- where item-property-value ('George Washington'-'date of birth'-'February 22, 1732') corresponds to a subject-predicate-object RDF triplet -- is also evidence of a fundamental link between Wikidata and W3C recommendations like RDF. And if you look in the 'Source' field of the property documentation for instance of (P31) and subclass of (P279), you'll see that they are derived from the rdf:type and rdfs:subClassOf properties from the W3C recommendation for RDF Schema. One cannot operate in Wikidata without bumping into W3C recommendations for the Semantic Web nearly everywhere.
Regarding your assertion that we don't have any practical use cases those W3C-based 'instance of' and 'subclass of' properties, I would say that replacing infobox parameters that define a subject's type -- like this 'ship class' property does -- is a clear example of a practical use case. 'instance of' could be incorporated into the infobox for USS Nimitz just like 'ship class'. In other words, it is merely a matter of using instance of (P31) instead of ship class (P289) in e.g. Template:Sclass/core, which Ships infoboxes use for class information. The difference is that 'instance of' is easy to reuse in other domains of knowledge, which makes it possible to link 'type of' information across domains. That has many useful applications.
By favoring home-grown type properties like "ship class" instead of standards-based type properties like instance of (P31), we would encourage the needless creation of redundant properties, make Wikidata less interoperable with the rest of the Semantic Web, and make applications that link knowledge across domains more difficult. We should avoid doing that, and delete properties like this redundant 'ship class' property that encourage those bad practices. Emw (talk) 16:07, 1 June 2013 (UTC)
Comment imho it is hard to decide if delete or not this property, because 1) this deletion will involve other specific type properties; 2) before to delete this property, we need to establish how to apply generic type properties to the "ship items". For me this discussion is very important for the future of organization of Wikidata items, so I open a request for comment concerning this topic. I ask all of you to add your comment. --Paperoastro (talk) 21:57, 1 June 2013 (UTC)
My inclination, as with most such properties in the form of 'type of', is to delete, largely per Emw's. The database simply becomes unmanageable with the more special-use terminology we use. --Izno (talk) 20:25, 9 June 2013 (UTC)
If instance of (P31) (i.e., rdf:type) makes Semantic Web implementations unmaintainable, then this is very big news. The claim that "the diversity of items pointed to by instance of (P31) would be unmaintainable" without domain-specific P31 properties requires supporting evidence. Emw (talk) 00:17, 26 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.
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 Свойство нужно для ru:Шаблон:Космическая экспедиция, где требуется именно фотография экипажа и ничто иное. image (P18) может содержать любые изображения, механизм квалификаторов здесь слабо помогает, т. к. текст квалификатора недетерменирован и слабо подходит для автоматизированной обработки. К тому же непонятно зачем усложнять код карточки алгоритмом распознавания типа изображения по значению квалификатора, когда можно это сделать на уровне свойств. — Ivan A. Krestinin (talk) 22:41, 9 June 2013 (UTC)
So, shouldn't we have "image of vehicle's wheels" or "birth image" then? Instead, I don't see why we are using special properties when we have qualifiers. --Ricordisamoa23:30, 9 June 2013 (UTC)
Если шаблон ru:Шаблон:Персона будет содержать свойство "birth image", то да, мы будем создавать такое свойство. Про квалификаторы уже пояснил, квалификаторы - это всего лишь строки с недетерменированным содержимым. Они не предназначены для обработки их в скрипте. — Ivan A. Krestinin (talk) 23:47, 9 June 2013 (UTC)
Я что-то главное упустил. image (P18) содержит изображение объекта статьи. В данном случае объект статьи - это космический аппарат. Ракета-носитель, экипаж - это даже не части этого аппарата. Потому использовать свойство image (P18) для размещения фотографии экипажа некорректно. А то если продолжить эту логику, то в айтем Earth (Q2) можно добавить практически любое изображение снабдив его квалификатором "находится на Земле". Некорректные значения я удалил. — Ivan A. Krestinin (talk) 17:57, 10 June 2013 (UTC)
Before a new property is created, it has to be discussed here. When after some time there are some supporters, but no or very few opponents, the property is created.
This property had no supporters and no opponents, it wasn't discussed by anyone. So why did you create it? Mushroom (talk) 17:53, 10 June 2013 (UTC)
Delete. Redundant and I don't understand why this is even made. There was only proposer, not other opinions. --Stryn (talk) 07:29, 10 June 2013 (UTC)
I think this property should be deleted for two reasons: first, because it was created without any discussion; second, because if we go down this road we'll end up having countless image properties, e.g. "team photo" for a sports event, "band photo" for a music concert, maybe even "killer photo" for a violent crime. If you think using image (P18) with qualifiers is incorrect, you could create an item for every mission crew and add image (P18) to it, then retrieve the photo from there. Mushroom (talk) 18:50, 10 June 2013 (UTC)
Это свойство обсуждалось в течении 2 месяцев, сколько по вашему оно должно было ещё обсуждаться? Идея с созданием отдельного айтема довольно интересная. Однако возможно ли использовать в карточке свойство какого-либо иного айтема, нежели связанного через механизм sitelinks? — Ivan A. Krestinin (talk) 19:37, 10 June 2013 (UTC)
The property has to have some supporters before being created, but in this case there were none apart from you. As for the second question, I'm sorry but I don't understand it because I can't speak Russian and Google Translate only goes so far. I'm not a native speaker of English either, but I think it's better for everyone if we all use a common language for these discussions. Otherwise I'm afraid I can't understand you properly. Mushroom (talk) 09:26, 11 June 2013 (UTC)
International project degrade to English project :-) Your position on the first question is very slighting to property proposer because he must wait for some unknown people for unknown period of time. If the theme is not very popular he can wait for years. I think we must be more friendly and open project then you propose. The second question was about usage "crew item" in infobox: is it possible to use item that is not linked using sitelinks? And what property to use to link crew and spacecraft items? — Ivan A. Krestinin (talk) 19:23, 11 June 2013 (UTC)
I am the one that's more than likely going to wind up closing the discussion and thus far I've been able to Google Translate my way through everything you've said, so if you want to speak in Russian, I at least don't have a problem with it. Sven ManguardWha?22:27, 11 June 2013 (UTC)
Not yet. That's why phase 2 started way too early. I strongly discourage the usage of Wikidata information in the Wikipedias until there is a solution. —★PοωερZtalk21:35, 14 June 2013 (UTC)
Keep - I looked at the only current example (Soyuz TMA-8 (Q1231148)) and the different articles that go with it. A space mission can have a number of different pictures: the crew, the space ship, the mission insignia, the launch site, a shot of the crafts interior or exterior in space. A lot of these images can be handled as qualifiers using the image (P18). The crew is more difficult because if there are 3 people then we would have each person with an image qualifier. So this property might be a good way of handling this. Trying to squeeze everything in the qualifiers has its downsides. Should the place of birth be the qualifier of the birthday or the other way around? If you can't establish the causation then your not looking at a qualifier in my opinion. --Tobias1984 (talk) 21:52, 14 June 2013 (UTC)
I don't think "image (P18) must contain images of item object." is true. The description in en is simply "a relevant image" and not "an image of the item". So your claim is false. :) --Izno (talk) 19:22, 15 June 2013 (UTC)
In Russian it has more strong name... I think so wide and non-deterministic usage of P18 property make it useless. This makes this property equals to Commons category. So, can I run bot that imports all filenames from every corresponding Commons category as P18? :-) Another think: why we have multiple properties with "image" type? Lets delete all of them and stay only P18 and specify everything in qualifiers. Where is boundary between P18+qualifier and separate property? — Ivan A. Krestinin (talk) 20:14, 15 June 2013 (UTC)
Hi Ivan! Sorry, I don't speak Russian either. I think you're raising a good question. We should have a clear guideline for properties that link to images. I think as we go along we learn a lot and sometimes a good decision from a while back seems bad by today's standards. --Tobias1984 (talk) 20:41, 15 June 2013 (UTC)
You raise a good question, and it's not the only property that could use answers for it. I would definitely suggest you start an WD:RFC. :) --Izno (talk) 22:20, 17 June 2013 (UTC)
@Izno: Thanks. Haven't looked at that revision. I guess that is also a good way of handling it. This way we could also accommodate more stages of the mission with a picture. --Tobias1984 (talk) 06:37, 15 June 2013 (UTC)
Delete There are simple to many objects (in facts: everything) a photo can show. It isn't possible to create for all and everythin a own property. --Nightwish62 (talk) 07:40, 1 August 2013 (UTC)
Deleted John F. Lewis (talk) 20:15, 12 June 2013 (UTC)
Delete Would be best handled some other way such as part of (P361). Many things are located on or in other things, so probably best to use a generic property rather than lots of specific ones. Danrok (talk) 23:47, 22 May 2013 (UTC)
Comment I think we should focus on the question whether identifying the island a place is on is important or not and should be done through a property. If yes, I think P526 is an easy way to enter this information and retrieve it. I don't think the other suggestions address this. -- Docu at 06:57, 25 May 2013 (UTC)
Question How is that a problem? —★PοωερZtalk 07:17, 25 May 2013 (UTC)
Support 'located in terrain feature' or 'located in natural geographical feature'. Filceolaire (talk) 23:02, 2 June 2013 (UTC)
Keep: useful precision. Ayack (talk) 18:49, 7 June 2013 (UTC)
Comment I would've voted for delete, but apparently according to the discussion linked above Lua can't currently handle non-flat links to Wikidata items, which means these need to be kept until we can sort out how to generate the entire taxonomical tree on Wikipedia by iteration. Deryck Chan (talk) 23:02, 2 June 2013 (UTC)
On hold There is a mess of merged articles in this subject in the domain I have been working with (Poland and Sweden). P237 cannot be used in this way until the possibility to use redirects as sitelinks starts to work. This because, in many cases counties, provinces, municipalities and cities are using the same coa. And in almost every case I have seen, the article about the coa not only describe one coa, but a group of coa's in a region. But I like the idea of using P237 and P18 in this way. -- Lavallen (block) 19:34, 20 May 2013 (UTC)
Doing… - Consensus to delete. John F. Lewis (talk) 16:35, 28 June 2013 (UTC)
Oppose because we will plenty of redundancy. We will have enough problems with unit symbol when including symbols of specific sicences like crystallography, quatum mechanic,... so the best solution is to start with unit symbol, Unicode symbol and element symbol. Snipre (talk) 17:06, 26 May 2013 (UTC)
Info. This property has already been proposed for deletion once 6 deletes and 11 keeps: Wikidata:Requests_for_deletions/Archive/2013/Properties/1#Property:P107. --Zolo (talk) 19:47, 17 June 2013 (UTC)
Info I have made a proposal at Help talk:High-level classification. I think it would cover all arguably useful uses of P107. --Zolo (talk) 07:13, 20 June 2013 (UTC)