Wikidata:Properties for deletion

Wikidata:Properties for deletion/Header/en

Property:P526

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

Deleted John F. Lewis (talk) 20:15, 12 June 2013 (UTC)[reply]

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οωερZ_{_talk} 15:19, 17 May 2013 (UTC).[reply]

Where is the "located in geographical region"-property? -- Lavallen (block) 15:22, 17 May 2013 (UTC)[reply]

We don't have one yet. —★PοωερZ_{_talk} 15:25, 17 May 2013 (UTC)[reply]

Cannot part of (P361) be used for "located in geographical regions"? -- Lavallen (block) 18:10, 17 May 2013 (UTC)[reply]

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)[reply]
- How do you think this should be differentiated? "probably best" seems hard use a criterion. -- Docu at 04:00, 23 May 2013 (UTC)[reply]

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)[reply]

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)[reply]
- I would like to see P131 changed to "located in geographical feature". -- Lavallen (block) 06:51, 25 May 2013 (UTC)[reply]
- "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)[reply]

OK, so how about located in/on the landform? Danrok (talk) 15:00, 25 May 2013 (UTC)[reply]

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)[reply]
- 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)[reply]
  - Question How is that a problem? —★PοωερZ_{_talk} 07:17, 25 May 2013 (UTC)[reply]
    - 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)[reply]
      - 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οωερZ_{_talk} 14:50, 25 May 2013 (UTC)[reply]

We also have P295 (P295) which is a similar concept. Danrok (talk) 15:09, 25 May 2013 (UTC)[reply]

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 - Talk 06:44, 28 May 2013 (UTC)[reply]

Support 'located in terrain feature' or 'located in natural geographical feature'. Filceolaire (talk) 23:02, 2 June 2013 (UTC)[reply]

Keep: useful precision. Ayack (talk) 18:49, 7 June 2013 (UTC)[reply]
Delete: what a ridiculous label... it wouldn't be the first deleted property by Docu. --Ricordi samoa 23:33, 9 June 2013 (UTC)[reply]
There's no need to make this personal. We can disagree and still be civil. Superm401 - Talk 00:01, 12 June 2013 (UTC)[reply]
Delete per above. Mushroom (talk) 18:11, 10 June 2013 (UTC)[reply]

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

I've proposed "located on terrain feature" (as discussed above) at Wikidata:Property proposal/Place#located on terrain feature. Superm401 - Talk 17:48, 14 June 2013 (UTC)[reply]

Property:P92 (legal basis)

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)[reply]

Support. Side note: we may need a property for this use case. --Zolo (talk) 17:31, 21 May 2013 (UTC)[reply]

Delete so long as it is now redundant. Danrok (talk) 23:49, 22 May 2013 (UTC)[reply]

Keep seems to be the more general concept. -- Docu at 06:08, 26 May 2013 (UTC)[reply]

Sorry: legal basis is more general than stated in ? Snipre (talk) 13:36, 26 May 2013 (UTC)[reply]

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)[reply]

Yes, I did mean foundational text (P457). stated in (P248) seems primarily to be for sourcing, not to provide information. -- Docu at 03:30, 29 May 2013 (UTC)[reply]

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)[reply]

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)[reply]

P100 (P100)

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. --Ricordi samoa 22:23, 6 June 2013 (UTC)[reply]

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)[reply]

Support Redundant. —★PοωερZ_{_talk} 12:55, 19 May 2013 (UTC)[reply]
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)[reply]

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)[reply]
- All of us agree the state restriction isn't viable. So you are actually proposing flooding items like the Order of the British Empire with way over 100,000 members. —★PοωερZ_{_talk} 20:47, 19 May 2013 (UTC)[reply]
  - Have you actually built anything recently? -- Docu at 21:01, 19 May 2013 (UTC)[reply]
    - Is this supposed to be a PA? —★PοωερZ_{_talk} 21:03, 19 May 2013 (UTC)[reply]
      - 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)[reply]
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)[reply]
Support. This property never made sense to me, I'd rather use member of (P463). Mushroom (talk) 22:46, 2 June 2013 (UTC)[reply]
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)[reply]

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

Property:P94

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)[reply]

coat of arms image (P94): (delete | history | links | entity usage | logs | discussion) coat of arms image (P94) | Is redundant to coat of arms (P237) and image (P18). —★PοωερZ_{_talk} 02:16, 20 May 2013 (UTC).[reply]

Delete. --Yair rand (talk) 02:30, 20 May 2013 (UTC)[reply]

(Note that this property is being used by certain infoboxes on the Swedish Wikipedia. --Yair rand (talk) 02:32, 20 May 2013 (UTC))[reply]

Comment Note that image is (wrongly imo) up for deletion. Secretlondon (talk) 13:11, 20 May 2013 (UTC)[reply]

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)[reply]
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)[reply]
- 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)[reply]

Keep per Wikidata:Properties_for_deletion#Property:P41. -- Docu at 06:33, 26 May 2013 (UTC)[reply]
Keep per Lavallen Sven Manguard Wha? 02:36, 1 June 2013 (UTC)[reply]
Delete per nomination. Mushroom (talk) 18:10, 10 June 2013 (UTC)[reply]
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)[reply]

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

Property:P527

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

The result is no consensus achieved for deletion.--Jasper Deng (talk) 23:47, 14 June 2013 (UTC)[reply]

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οωερZ_{_talk} 02:52, 20 May 2013 (UTC)[reply]

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)[reply]
- 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)[reply]
  - 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)[reply]

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)[reply]

Comment As it stands the label and description are nonsensical. Danrok (talk) 13:20, 20 May 2013 (UTC)[reply]
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)[reply]
How is this not accomplished with just the part of (P361) property? --Yair rand (talk) 20:18, 20 May 2013 (UTC)[reply]
part of (P361) is for the other direction as far as I have understood. Austria is a part of (P361) Europe but Europe is not a part of (P361) of Austria. -- Lavallen (block) 07:01, 21 May 2013 (UTC)[reply]
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)[reply]
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)[reply]

Delete, per 23PowerZ and Yair rand. We should delete it before people begin using it. --Ricordi samoa 23:24, 20 May 2013 (UTC)[reply]
Comment See also #Property:P131 below. -- Lavallen (block) 08:00, 21 May 2013 (UTC)[reply]
Delete Snipre (talk) 17:30, 21 May 2013 (UTC)[reply]

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)[reply]

Cider do not consist of apples, it is made of apples. That is a different thing in my opinion. Byrial (talk) 07:37, 25 May 2013 (UTC)[reply]

Eh? Definition of consists: To be made up or composed of. Danrok (talk) 14:13, 25 May 2013 (UTC)[reply]

Keep, but limit usage to cases where there aren't enough objects to warrant a list. That is to say, United States shouldn't have links to all 50 states since there exists a List of U.S. states, but Dzhokhar and Tamerlan Tsarnaev should have links to Dzhokhar Tsarnaev and Tamerlan Tsarnaev. To cover the remaining cases, there should be a "list of members" property or something similar, which would link to the item(s) on the relevant list(s). This would actually be really useful for items like President of the United States, which has a whole lotta lists. — PinkAmpers&^{(Je vous invite à me parler)} 02:07, 25 May 2013 (UTC)[reply]
- Intresting idea! I Support that! -- Lavallen (block) 06:54, 25 May 2013 (UTC)[reply]
- 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

Byrial (talk) 07:37, 25 May 2013 (UTC)[reply]
Delete,If reverse quering for what are part of (P361) of a specific item is as fast as quering for the values of has part(s) (P527) of that item.--凡其 _Fanchy 17:23, 2 June 2013 (UTC)[reply]
Delete Redundant inverse of P:P361, per above. Deryck Chan (talk) 22:54, 2 June 2013 (UTC)[reply]
Delete per above. Mushroom (talk) 23:11, 2 June 2013 (UTC)[reply]
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)[reply]
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)[reply]
Keep I'm using this one! See Wikidata talk:Cultural heritage task force#Rijksmonumenten in the Netherlands. Multichill (talk) 20:32, 11 June 2013 (UTC)[reply]

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

Property:P158

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 per consensus of comments. Sven Manguard Wha? 23:42, 13 June 2013 (UTC)[reply]

seal image (P158): (delete | history | links | entity usage | logs | discussion) seal image (P158) | Redundant to has seal, badge, or sigil (P418) and image (P18). —★PοωερZ_{_talk} 02:36, 20 May 2013 (UTC).[reply]

Useful for infoboxes - how to select the right image if item have several images? JAn Dudík (talk) 08:13, 20 May 2013 (UTC)[reply]
Comment Note that image is up for deletion above. Secretlondon (talk) 13:12, 20 May 2013 (UTC)[reply]

Keep per Wikidata:Properties_for_deletion#Property:P41 -- Docu at 07:26, 26 May 2013 (UTC)[reply]
Keep Similar comment as mine at coat of arms image (P94): This property is not redundant to has seal, badge, or sigil (P418): It provides an actual seal image, not just the link to an article about the seal. This is more specific than image (P18); more specific properties (such as this one) should always be used instead.

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

Property:P265

P265 (P265): (delete | history | links | entity usage | logs) P265 (P265) | Redundant to part of (P361). (Also lack of consensus) —★PοωερZ_{_talk} 02:41, 20 May 2013 (UTC).[reply]

required for en:Template:Infobox lake, part of the series of properties proposed for that. -- Docu at 07:51, 20 May 2013 (UTC) (edited)[reply]
- Question: Please tell why you don't think that part of (P361) can used be instead of this? Byrial (talk) 15:03, 25 May 2013 (UTC)[reply]
  - 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)[reply]

Well, part of (P361) can used if combined with instance of (P31) group of lakes (Q5926864). However an other way to go might be to generalise this property to mean "belongs to group of the same kind". Examples:

Islands: Mallorca (Q8828) group Balearic Islands (Q5765)
Mountains: Mount Everest (Q513) group Mahalangur Himal (Q924257), Himalayas (Q5451) (would obsolete P295 (P295))
Persons: Romulus (Q2186) group Romulus and Remus (Q2197)
Roads: California State Route 52 (Q19191) group state highways in California (Q400256) (would obsolete transport network (P16))

There would probably also be many other areas, where this could used. Byrial (talk) 08:27, 26 May 2013 (UTC)[reply]

I feel that part of (P361) fits already quite well for all these cases. So P265 (P265) is redundant. Infovarius (talk) 13:04, 3 June 2013 (UTC)[reply]
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.

Later we can get the devs to add a special subproperty (W3C approved) so we can identify P265 (P265) as a subproperty of part of (P361). Filceolaire (talk) 08:01, 6 June 2013 (UTC)[reply]

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)[reply]
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)[reply]

I think the consensus is for hundreds of specific properties. Filceolaire (talk) 07:32, 15 June 2013 (UTC)[reply]

Delete. Replace with proposed property Wikidata:Property_proposal/Place#located on terrain feature (en) Filceolaire (talk) 07:25, 15 June 2013 (UTC)[reply]
- 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)[reply]

Property:P201

outflows (P201): (delete | history | links | entity usage | logs | discussion) Merge outflows (P201) with mouth of the watercourse (P403) and rename to the more general discharges into. (Also lack of consensus and complete lack of consensus) —★PοωερZ_{_talk} 03:14, 20 May 2013 (UTC).[reply]

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)[reply]

required for en:Template:Infobox lake, part of the series of properties proposed for that. -- Docu at 07:51, 20 May 2013 (UTC) (edited)[reply]
- Stop being sarcastic. You should really read Wikidata:Property creators for once. —★PοωερZ_{_talk} 13:43, 20 May 2013 (UTC)[reply]
Couple of points.

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)[reply]
- Discharge is the hydrological terminus. —★PοωερZ_{_talk} 13:53, 20 May 2013 (UTC)[reply]
  - Actually, it isn't. Read the first sentence of the article.--Jakob ^{Scream about} _{the things I've broken} 22:27, 20 May 2013 (UTC)[reply]

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)[reply]
- The reason is that you can do consistency checks easily. -- Docu at 06:25, 26 May 2013 (UTC)[reply]
  - I see no problem with consistency checks. You can check if the merged property is used for an instance of a subclass of body of water. Here is another example where the merged property can be used: Adriatic Sea (Q13924) discharges into Ionian Sea (Q37495) Byrial (talk) 10:09, 26 May 2013 (UTC)[reply]

I recommend not to use it for seas, because as you can see:

Well, maybe the example wasn't good. I took it from the infobox at en:Adriatic Sea without further investigation. Byrial (talk) 11:28, 26 May 2013 (UTC)[reply]

Property:P200

inflows (P200): (delete | history | links | entity usage | logs | discussion) inflows (P200) | See above. It's already widely misused (example) and becomes redundant by a discharges into property. (Also lack of consensus)—★PοωερZ_{_talk} 03:17, 20 May 2013 (UTC).[reply]

required for en:Template:Infobox lake, part of the series of properties proposed for that. -- Docu at 07:51, 20 May 2013 (UTC) (edited)[reply]

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)[reply]

See previous property discussion above (P201). -- Docu at 06:26, 26 May 2013 (UTC)[reply]

General Discussion

Question: Do I understand correctly that the proposal is to merge inflows (P200), outflows (P201) and mouth of the watercourse (P403) to one? Would you please give some illustrative examples of how the merged property is intended to be used for both rivers and lakes? Thank you, Byrial (talk) 15:03, 25 May 2013 (UTC)[reply]
- Of course: Most bodies of water have multiple inflows and either only one outflow or none at all (= endorheic). Inflows can be deduced from the outflow property so this would be enough. It also allows us to check for false data as every statement can only have one item and things like A → B → C → A are impossible. As an example: Lake Superior (Q1066) → St. Marys River (Q940488) → Lake Huron (Q1383) → St. Clair River (Q1054325) → Lake Saint Clair (Q736707) → Detroit River (Q318435) → Lake Erie (Q5492) → Niagara River (Q182343) → Lake Ontario (Q1062) → St. Lawrence River (Q134750) → Gulf of Saint Lawrence (Q169523) part of (P361): Atlantic Ocean (Q97). All of these items have hundreds of additional inflows, but if you want a list of, let's say, all the inflows of Lake Superior, you can just query for it. Distinguishing between lakes and rivers just over complicates things and I don't see any need to as this is already stated by instance of (P31). —★PοωερZ_{_talk} 15:46, 25 May 2013 (UTC)[reply]
  - 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)[reply]
    - The current system doesn't solve these problems either. In any case you need qualifiers, like this proposal that can show which are the main inflows. For a lake a river flows through (e.g. Rhine (Q584) through Lake Constance (Q4127)) we have lake on watercourse (P469). —★PοωερZ_{_talk} 18:40, 25 May 2013 (UTC)[reply]
  - 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)[reply]

Property:P75

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)[reply]

P75 (P75): (delete | history | links | entity usage | logs) As it was stated on the property's discussion page, this property is redundant to parent taxon (P171) and I completely agree. Could someone with a little more knowledge of Hebrew than me notify hewiki about the deletion discussion as they seem to use it? —★PοωερZ_{_talk} 15:05, 25 May 2013 (UTC).[reply]

Comment See Wikidata:Requests for comment/Inheritance of taxon ranks. --Succu (talk) 15:57, 25 May 2013 (UTC)[reply]

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)[reply]

Keep it's in use, valid and recursion is not possible yet. Also see the comments on the rfc. Multichill (talk) 18:17, 8 June 2013 (UTC)[reply]

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

Property:P558

P558 (P558): (delete | history | links | entity usage | logs) Merge P558 (P558) with quantity symbol (string) (P416). The only difference is whether the item is a unit or a quantity, so this can be done by one property. —★PοωερZ_{_talk} 04:07, 26 May 2013 (UTC)[reply]

What to merge it alsog with Unicode character (P487) ? It the two ones you mentioned are subclasses of P487. --Pyfisch (talk) 11:09, 26 May 2013 (UTC)[reply]

Support merging P558 (P558) with quantity symbol (string) (P416). Unicode symbol is something else. Snipre (talk) 16:43, 26 May 2013 (UTC)[reply]

If you want to merge all symbol properties with string valuetype, we also have element symbol (P246). Byrial (talk) 16:53, 26 May 2013 (UTC)[reply]

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)[reply]

Question Can you give an example of a possible problem? —★PοωερZ_{_talk} 17:11, 26 May 2013 (UTC)[reply]

Comment: I don't see any possible problem, for example:

--Ricordi samoa 18:02, 26 May 2013 (UTC)[reply]

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)[reply]

temperature (Q11466) symbol: "T"; unit: degree Celsius (Q25267), kelvin (Q11579); degree Celsius (Q25267) symbol: "°C"; kelvin (Q11579) symbol: "K". Yes unit and symbol are different: Unit is datatype item, so there is no problem. —★PοωερZ_{_talk} 18:56, 26 May 2013 (UTC)[reply]

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)[reply]

Nobody said that, the proposal is to have one for the symbol. —★PοωερZ_{_talk} 12:41, 27 May 2013 (UTC)[reply]

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)[reply]

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)[reply]

P558 (P558) is string datatype used to show which symbol a unit uses: Special:WhatLinksHere/Property:P558, and that's also what the property's proposal speaks of. I agree, we lack a unit property, but that doesn't have anything to do with this merge proposal. —★PοωερZ_{_talk} 16:09, 27 May 2013 (UTC)[reply]

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)[reply]

Again, P558 (P558) doesn't do this task. —★PοωερZ_{_talk} 18:56, 27 May 2013 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Comment. measured physical quantity (P111) is used to refer to the quantity measured (e.g. speed (Q3711325)) from the measurement unit (e.g. kilometre per hour (Q180154)) but we are missing a "measurement unit" property with an item datatype which P558 (P558) or quantity symbol (string) (P416) (string datatypes) give the abbreviation for (km/hr). Filceolaire (talk) 07:14, 6 June 2013 (UTC)[reply]

Keep or Merge P558 (P558) but create new property with item datatype for the full name of the measurement unit. Filceolaire (talk) 07:14, 6 June 2013 (UTC)[reply]

Summary

temperature (Q11466)

symbol (string): "T"

unit (item): degree Celsius (Q25267)

unit (item): kelvin (Q11579)

degree Celsius (Q25267)

measured physical quantity (P111) (item): temperature (Q11466)

symbol (string): "°C"

kelvin (Q11579)

measured physical quantity (P111) (item): temperature (Q11466)

symbol (string): "K"

heat capacity (Q179388)

symbol (string): "Cp"

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)[reply]

What? —★PοωερZ_{_talk} 14:07, 13 June 2013 (UTC)[reply]

What what ? :). I just want to find a global solution for unit and symbol before any deletion. Snipre (talk) 14:14, 13 June 2013 (UTC)[reply]

And I don't understand your problem, apparently. —★PοωερZ_{_talk} 14:24, 13 June 2013 (UTC)[reply]

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:

heat capacity (Q179388)

symbol (string): "Cp"

symbol (string): kJ/(kg °C)

Filceolaire (talk) 15:42, 13 June 2013 (UTC)[reply]

Property:P150

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

Delete Redundant. —★PοωερZ_{_talk} 18:18, 26 May 2013 (UTC)[reply]
Delete. --Yair rand (talk) 22:47, 26 May 2013 (UTC)[reply]
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)[reply]
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. T C N7JM 02:15, 27 May 2013 (UTC)[reply]
On hold per TCN7JM. --Stevenliuyi (talk) 03:32, 27 May 2013 (UTC)[reply]
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)[reply]
If/once P131 is kept, Delete. T C N7JM 06:37, 27 May 2013 (UTC)[reply]
- Today, I do not think P131 has to be deleted, but it's purpose has to be more obvious. -- Lavallen (block) 07:32, 27 May 2013 (UTC)[reply]
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)[reply]
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. --Ricordi samoa 07:39, 27 May 2013 (UTC)[reply]
"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.

-- Lavallen (block) 08:16, 27 May 2013 (UTC)[reply]
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οωερZ_{_talk} 11:27, 27 May 2013 (UTC)[reply]
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)[reply]
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)[reply]
Keep as Ymblanter. --Stryn (talk) 16:29, 27 May 2013 (UTC)[reply]
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". T C N7JM 17:10, 27 May 2013 (UTC)[reply]
I'm not proposing to delete this property for being redundant with has part(s) (P527): I simply find nonsensical to have Karlovy Vary Region (Q191091) <contains the administrative territorial entity (P150)> Cheb District (Q628280), Sokolov District (Q833856), Karlovy Vary District (Q757240) when we should have "located in the administrative territorial entity (P131) → Karlovy Vary Region (Q191091)" for each of Cheb District (Q628280), Sokolov District (Q833856) and Karlovy Vary District (Q757240). --Ricordi samoa 00:02, 29 May 2013 (UTC)[reply]
but located in the administrative territorial entity (P131) → Karlovy Vary Region (Q191091) should be also in many different items, e.g. Q607053, Q1413814... and if I open Q191091, I can not see which parts have - only use whatlinksehere, where are many other links. JAn Dudík (talk) 20:18, 29 May 2013 (UTC)[reply]

I never said you were proposing that. I was replying to the person who mentioned P527 above. T C N7JM 02:11, 29 May 2013 (UTC)[reply]
Delete. Now that located in the administrative territorial entity (P131) is kept, this is pretty much redundant. (P131 was proposed for deletion not because it's the inverse of this one, but because it was similar to part of (P361).) Deryck Chan (talk) 22:57, 2 June 2013 (UTC)[reply]

Property:P289

vessel class (P289): (delete | history | links | entity usage | logs | discussion) Objects which are simply instances of a certain class should use instance of (P31), not a custom property. Ship classes are particularly straightforward, since "class" is used in ordinary language. In fact, Help:Basic membership properties uses Nimitz-class aircraft carrier (Q309336) as an example of proper instance of usage. Existing values should be migrated to P31. Superm401 - Talk 23:35, 28 May 2013 (UTC).[reply]

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)[reply]
Completely disagree. If there is a more general property, get rid of the redundancy. —★PοωερZ_{_talk} 11:55, 29 May 2013 (UTC)[reply]
"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)[reply]
In the infoboxes the ship-class is often followed by P288 (P288). There may be exceptions. Perhaps P288 (P288) should also be deleted in preference to instance of (P31)? Danrok (talk) 17:10, 29 May 2013 (UTC)[reply]
Danrok, the P288 (P288) values you refer to are the subclass of (P279) values for the item's instance of (P31) value. For example:
USS Nimitz (Q463161) instance of (P31) Nimitz-class aircraft carrier (Q309336) <- 'ship class'

Nimitz-class aircraft carrier (Q309336) subclass of (P279) supercarrier (Q1186981) <- 'watercraft type'

So I think P288 (P288) should be deleted, but replaced with subclass of (P279) instead of instance of (P31) in cases like the above. Emw (talk) 23:52, 29 May 2013 (UTC)[reply]
Agree. Danrok (talk) 15:06, 30 May 2013 (UTC)[reply]
It is correct to say that USS Nimitz (Q463161) is an instance of Nimitz-class aircraft carrier (Q309336). But, if we delete vessel class (P289), how can the ship's class be easily extracted and used in infoboxes on wikipedia? If that can be done, I've no objection to the deletion. Danrok (talk) 15:04, 29 May 2013 (UTC)[reply]
Take L as the list of items the ship's an instance of. Show each member of L if the member is an instance of ship class (Q559026) Superm401 - Talk 21:29, 29 May 2013 (UTC)[reply]
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)[reply]
Is there an example of the vessel class (P289) being used in an infobox to pull in data from Wikidata? instance of (P31) should be a drop-in replacement for this property in those cases. Emw (talk) 16:16, 1 June 2013 (UTC)[reply]
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 - Talk 05:46, 3 June 2013 (UTC)[reply]

That's a fair question, Docu. Unfortunately, I can't actually write the code until bugzilla:47930 is fixed, though I know how it needs to work (see above). Superm401 - Talk 05:46, 3 June 2013 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
I don't see an actual use of these things. -- Docu at 18:09, 2 June 2013 (UTC)[reply]
What do you mean? Would a prototype of such a use sway your opinion? Emw (talk) 18:17, 2 June 2013 (UTC)[reply]
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)[reply]
Keep per the discussion on Wikidata:Requests for comment/How to classify items: lots of specific type properties or a few generic ones?. There are thousands of ships. expecting editors to pick the right ship class using property instance of (P31) won't work. Having a special 'type of' property such as vessel class (P289) lets us include hints in the aliases for this property to help editors. Bots can also check that this property is only used to link to items with the instance of (P31) ship class and flag any discrepancies. Editors know the property name because it matches the name used in their infoboxes.
Later we can get the devs to add a special subproperty to identify vessel class (P289) as a subproperty of instance of (P31) but in the mean time we can get on with populating the data pages. Filceolaire (talk) 23:01, 5 June 2013 (UTC)[reply]
Keep per above. Clear domain. Multichill (talk) 18:21, 8 June 2013 (UTC)[reply]
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)[reply]

Property:P288

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

Delete (just like other "type of ;). --Zolo (talk) 16:32, 30 May 2013 (UTC)[reply]

Keep makes it easier to populate the related infobox field. -- Docu at 18:08, 2 June 2013 (UTC)[reply]

Delete. P288 (P288) is not like other "type of" properties as it is a super class of the ship types and is redundant as we can follow vessel class (P289) to the level above to see what watercraft type type a ship class is. Here we are defining a hierarchy of items so using a consistent property like subclass of (P279) makes sense. As it is only needs to be used on ship classes, not on ships, therefore it is used on many fewer items than vessel class (P289) so making it easier to use is not quite so important.

vessel class (P289) is used on every ship so we need it to be easy to use so it makes sense to have a "type of" property for this. Later we can get the devs to add a facility to define vessel class (P289) as a subproperty of instance of (P31). Filceolaire (talk) 22:37, 5 June 2013 (UTC)[reply]

Delete Redundant with subclass of (P279). Emw (talk) 00:53, 6 June 2013 (UTC)[reply]

Delete, per above. --Ricordi samoa 00:10, 15 June 2013 (UTC)[reply]

Property:P29 + Property:P139

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 Manguard Wha? 00:17, 14 June 2013 (UTC)[reply]

Bot got uncles, so everything's deleted. Sven Manguard Wha? 01:50, 14 June 2013 (UTC)[reply]

Bot "got" uncles, so we've lost many data... I've filed a comment. --Ricordi samoa 02:04, 14 June 2013 (UTC)[reply]

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).[reply]

Delete. These properties are clearly redundant, they add complexity without providing any real benefit. Mushroom (talk) 23:05, 2 June 2013 (UTC)[reply]

Delete. Completely redundant. --Yair rand (talk) 06:45, 3 June 2013 (UTC)[reply]

Delete. Redundant. --Magnus Manske (talk) 11:18, 3 June 2013 (UTC)[reply]

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)[reply]

Comment. A possible solution for those rare cases was proposed here. Mushroom (talk) 12:32, 4 June 2013 (UTC)[reply]

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)[reply]
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)[reply]

Comment The missing links on User:Byrial/Uncles should be fixed first. -- Docu at 19:57, 9 June 2013 (UTC)[reply]

Delete. You can find my reasons at Wikidata:Requests for comment/Kinship. —★PοωερZ_{_talk} 17:01, 6 June 2013 (UTC)[reply]

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)

Property:P387

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

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

I'm not even sure how this is intended to be used, where is the proposal discussion? —★PοωερZ_{_talk} 16:58, 6 June 2013 (UTC)[reply]

I think this was created without long discussion because of the corresponding parameter in a wikipedia infobox. Snipre (talk) 01:32, 7 June 2013 (UTC)[reply]

Delete per nom. --Ricordi samoa 22:25, 6 June 2013 (UTC)[reply]

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)[reply]

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)[reply]
- I agree, but it would have been better to discuss this prior to the property's creation. —★PοωερZ_{_talk} 20:38, 10 June 2013 (UTC)[reply]

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)[reply]

How about datatype? Should it be Monolingual texts?--GZWDer (talk) 16:01, 11 June 2013 (UTC)[reply]

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)[reply]

Keep only for use in sources. Filceolaire (talk) 08:58, 13 June 2013 (UTC)[reply]

Property:P623

P623 (P623): (delete | history | links | entity usage | logs) Redundant with image (P18) and some qualifiers. --Ricordi samoa 22:20, 9 June 2013 (UTC)[reply]

Keep Свойство нужно для ru:Шаблон:Космическая экспедиция, где требуется именно фотография экипажа и ничто иное. image (P18) может содержать любые изображения, механизм квалификаторов здесь слабо помогает, т. к. текст квалификатора недетерменирован и слабо подходит для автоматизированной обработки. К тому же непонятно зачем усложнять код карточки алгоритмом распознавания типа изображения по значению квалификатора, когда можно это сделать на уровне свойств. — Ivan A. Krestinin (talk) 22:41, 9 June 2013 (UTC)[reply]
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. --Ricordi samoa 23:30, 9 June 2013 (UTC)[reply]
Если шаблон ru:Шаблон:Персона будет содержать свойство "birth image", то да, мы будем создавать такое свойство. Про квалификаторы уже пояснил, квалификаторы - это всего лишь строки с недетерменированным содержимым. Они не предназначены для обработки их в скрипте. — Ivan A. Krestinin (talk) 23:47, 9 June 2013 (UTC)[reply]
Delete I've made an example here Soyuz TMA-8 (Q1231148) showing how we could do this using qualifiers. Danrok (talk) 00:14, 10 June 2013 (UTC)[reply]
- Вы бы лучше показали простой способ использования объединения двух свойств в карточке. — Ivan A. Krestinin (talk) 07:39, 10 June 2013 (UTC)[reply]
- Я что-то главное упустил. image (P18) содержит изображение объекта статьи. В данном случае объект статьи - это космический аппарат. Ракета-носитель, экипаж - это даже не части этого аппарата. Потому использовать свойство image (P18) для размещения фотографии экипажа некорректно. А то если продолжить эту логику, то в айтем Earth (Q2) можно добавить практически любое изображение снабдив его квалификатором "находится на Земле". Некорректные значения я удалил. — Ivan A. Krestinin (talk) 17:57, 10 June 2013 (UTC)[reply]
Speedy close: this was created just now. -- Docu at 05:44, 10 June 2013 (UTC)[reply]
- How is this a valid argument? —★PοωερZ_{_talk} 07:35, 10 June 2013 (UTC)[reply]

Our property proposal page states:

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)[reply]

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)[reply]
- Пояснил выше. — Ivan A. Krestinin (talk) 18:09, 10 June 2013 (UTC)[reply]
Delete per above. Mushroom (talk) 17:53, 10 June 2013 (UTC)[reply]
- Выше показано, что свойство image (P18) в данном случае не подходит. О чём тогда ваш комментарий? — Ivan A. Krestinin (talk) 18:09, 10 June 2013 (UTC)[reply]
  - 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)[reply]
    - Это свойство обсуждалось в течении 2 месяцев, сколько по вашему оно должно было ещё обсуждаться? Идея с созданием отдельного айтема довольно интересная. Однако возможно ли использовать в карточке свойство какого-либо иного айтема, нежели связанного через механизм sitelinks? — Ivan A. Krestinin (talk) 19:37, 10 June 2013 (UTC)[reply]
      - 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)[reply]
        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)[reply]
        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 Manguard Wha? 22:27, 11 June 2013 (UTC)[reply]
    - I find answer to my question: [1]. So idea with separate item for crew is not usable. — Ivan A. Krestinin (talk) 20:59, 14 June 2013 (UTC)[reply]
      - 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οωερZ_{_talk} 21:35, 14 June 2013 (UTC)[reply]

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)[reply]

Delete ~ What is stopping us from using Q345844 in the qualifier? (Tobias: Revision of interest is this one in case you didn't check.) --Izno (talk) 22:35, 14 June 2013 (UTC)[reply]
- I already wrote in Russian: image (P18) can not be used because item is about spacecraft. image (P18) must contain images of item object. Crew photo is not image of spacecraft. — Ivan A. Krestinin (talk) 04:04, 15 June 2013 (UTC)[reply]

@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)[reply]

Wikidata:Properties for deletion

Contents

Requests

Property:P526

Property:P92 (legal basis)

P100 (P100)

Property:P94

Property:P527

Property:P158

Lake infobox properties

Property:P265

Property:P201

Property:P200

General Discussion

Property:P75

Property:P558

Property:P150

Property:P289

Property:P288

Property:P29 + Property:P139

Property:P387

Property:P623

Navigation menu

Wikidata:Properties for deletion

Requests

Property:P92 (legal basis)

Lake infobox properties

General Discussion

Property:P29 + Property:P139

Navigation menu

Search