Wikidata:Properties for deletion/Archive/2013/4

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

Property:P423

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 to delete was not reached.--Jasper Deng (talk) 11:13, 17 November 2013 (UTC)

shooting handedness (P423): (delete | history | links | entity usage | logs | discussion) Merge to handedness (P552) with qualifier sport (P641).--GZWDer (talk) 05:24, 18 October 2013 (UTC)

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

Property:P16 (highway system)

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

The result was keep. --Jakob (Scream about the things I've broken) 18:07, 4 December 2013 (UTC)

transport network (P16): (delete | history | links | entity usage | logs | discussion) Reasons for deletion request:
a) Not a well-defined property, what exactly is a highway system. The value is often a "list of" page, which does not make much sense.
b) No clear benefit over using part of (P361) with an item describing the road network/system in a specific country or state (not a list).
Michiel1972 (talk) 14:17, 19 November 2013 (UTC)

 Keep It is not always a "list of" page; see Q623918.
As far as your second point, "part of" is typically used for roads being part of larger roads. This would make it hard for an infobox module to tell the difference between a road being part of another road, or part of a larger system. --Rschen7754 10:34, 21 November 2013 (UTC)
 Keep I'd be responsible for sorting this out in the infobox module, and I don't want to have to do the extra work needed to implement this. I have better things to do with my time than configuring modules to use the same property for completely different concepts. -happy5214 10:46, 21 November 2013 (UTC)
Can you explain what a highway system is? -- Lavallen (talk) 11:01, 21 November 2013 (UTC)
It is a system of highways, commissioned by a government. w:en:Template:Infobox road has a field set up specifically for this. --Rschen7754 20:12, 21 November 2013 (UTC)
For me it is still unclear what you mean with 'system', it is not a clear definition, or only applicable for some countries. I guess this property only refers to the English Infobox road and the US state highways per state. If this is true, maybe it is possible to rename this property to indicate it is usefull for US roads only, and should not be used for other roads in other countries. Can we call it "US highway system" or something? Michiel1972 (talk) 09:31, 26 November 2013 (UTC)
Not true; see Wikidata:Roads task force/Europe (which should be using the field, but is not). --Rschen7754 09:39, 26 November 2013 (UTC)
I can see that E4 and E004 both are instance of international E-road network (Q106123). -- Lavallen (talk) 20:18, 26 November 2013 (UTC)
Yes, though I don't really think that's the best place, for the same reason as why using part of is not a good answer either. --Rschen7754 20:34, 26 November 2013 (UTC)
 Keep Necessary property. "Highway system" is a fairly clear term. —Scott5114↗ [EXACT CHANGE ONLY] 00:28, 22 November 2013 (UTC)
 Keep - Neither point is correct. First, what a highway system is is self-explanatory; Rschen noted the definition above. Second, there is a benefit in using this over P361 because that is used for something completely different within the roads task force. For example, Q13419340 would be "part of" Q410689 because it highlights one state's section of the whole national route. TCN7JM 05:16, 22 November 2013 (UTC)
Even if the article on English wikipedia is called "List of <road system>" the item on Wikidata can have the label "<road system>" with "list of <road system>" as an alias.
On the other hand, if U.S. Route 83 in Oklahoma (Q13419340) is "part of" U.S. Route 83 (Q410689) then U.S. Route 83 (Q410689) can still be 'part of' Interstate Highway System (Q94247). Filceolaire (talk) 22:25, 25 November 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

P41 (flag image), P94 (coat of arms image), P154 (logo image), P207 (bathymetry image), P158 (seal image), P109 (signature), P367 (astronomic symbol image)

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.

Please discuss below.--GZWDer (talk) 10:33, 7 December 2013 (UTC)

Merge to image (P18) with qualifier per Wikidata:Requests for comment/Image properties: many properties or many qualifiers.--GZWDer (talk) 09:36, 23 November 2013 (UTC)

And also: P15 (road map), P117 (chemical structure), P181 (range map), P242(locator map image), P491 (orbit diagram), P692 (Gene Atlas Image) --GZWDer (talk) 08:47, 24 November 2013 (UTC)
One problem I have seen with P41 is that a "banner of arms" have been added instead of a flag. -- Lavallen (talk) 11:22, 24 November 2013 (UTC)

See also Wikidata:Requests_for_deletions/Archive/2013/Properties/1#Property:P41. JAn Dudík (talk) 06:36, 25 November 2013 (UTC)

 Keep
  • 1) is not good to vote all of them in one pack - some of them could be keeped, some deleted.
  • 2) Using property without qualifier is much easier than select one with qualifier. So keep ninimally P41 and P94 which are (both) used by (the same) infoboxes. Can any of supporters rewrite all templates in all wikis which are using these properties (I am afraid there is not many people understanding lua in smaller wikis)?
JAn Dudík (talk) 06:30, 25 November 2013 (UTC)
 Wait Please put {{Property for deletion}} on all property talk pages and inform all people which are using these properties in wikipedia. --Pasleim (talk) 08:12, 25 November 2013 (UTC)
 Keep, prop+qualifier scheme has many problems. One of them: Wikidata talk:Requests for comment/Image properties: many properties or many qualifiers#Algorithm for infoboxes. — Ivan A. Krestinin (talk) 08:02, 25 November 2013 (UTC)
 Keep What the heck? I didn't even know that P15 was up for deletion. This should be speedy closed, and proper nomination procedures should be followed. --Rschen7754 20:30, 3 December 2013 (UTC)
Perfectly said: What the heck? People who proposed the property and the projects that widely use them need to be informed if they're being put up for deletion. TCN7JM 18:32, 4 December 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Short name, Birth name, Official name

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

 Not deleted - no consensus to delete.--Jasper Deng (talk) 03:55, 9 December 2013 (UTC)

Delete P513 (P513), P743 (P743) and proposed property Official name and replace with new property 'Name' (with monolingual datatype).

People and things have all kinds of names. If we have a separate property for each type of name then an infobox or a query must guess which property has been used for an item. If all names use the same property then it is easier to find a persons names. When we have ranks we can mark one name as preferred. We can use instance of (P31) as a qualifier to indicate the type of name (birth name, pen name, stage name, nom de guerre, legal name) or start date/end date as qualifiers where a name is changed. Filceolaire (talk) 22:19, 7 November 2013 (UTC)

 Delete Same as "first name" (Property:P153). --Kolja21 (talk) 22:36, 7 November 2013 (UTC)
 Delete P513 (P513) without replacing it; it's redundant to the personal name properties. If you need something's simple name, use the label, not a property. Anything else is complex data, and shouldn't use a simple "Name" property without giving further information. --Yair rand (talk) 00:14, 8 November 2013 (UTC)
I Don't agree that birth name is redundant to the 'given name' 'surname' properties - people can change their name or can use an alias spelling so a property with monolingual text datatype is also required to give the exact spelling and the order of their birth and sur names (where people have middle names and double barelled surnames). Often people use various names. If they are famous then they may have their name transliterated in the title of wikipedia articles in other languages. In these cases the label is not not enough. We need a property to (for example) tell chinese people that '布鲁斯·斯普林斯廷' is known in his own language as 'Bruce Springsteen'. Also note that I didn't say we should use 'Name' without giving further information; the proposal is that qualifiers be used for the necessary further information. Filceolaire (talk) 16:45, 8 November 2013 (UTC)
 Comment Re: "Short name", it was me who proposed it. The intension was to use it when you need to design links like: "[[Stockholms kommun|Stockholm]]", like in navigation-templates, where the "short name" often is used. Having "Stockholm" in the label doesn't make sense, at least not in Swedish. It's not only wrong, it's also misleading. I agree that the datatype maybe isn't correct. I guess we need a "multilingual datatype" to describe it correctly. -- Lavallen (talk) 08:38, 8 November 2013 (UTC)
I would be very strongly against using 'multilingual' datatype. I think it should be 'monolingual' so we can use it for the 'official' spelling and we don't tempt people to do their own unofficial transliterations. We should probabl;y have a separate 'translation/transliteration' property with multilingual datatype which could be used as a qualifiers in a lot of cases but that is a separate issue. Filceolaire (talk) 16:52, 8 November 2013 (UTC)
There is nothing official with a short name. The official name of Stockholm Municipality is "Stockholms kommun" according to the Swedish municipality-law, but "Stockholms stad" according to Stockholm municipality counsil. Both of them are official, but "Stockholm" is not official anywhere. Short name is a property to make it easier to make templates that do not need the full official name or label. The portugese short name could be "Estocolmo" and the Finnish "Tukholma". But that is up to some fi- or pt-speakers to decide. -- Lavallen (talk) 18:38, 8 November 2013 (UTC)
 Comment No 2. Does it today make sense to propose a property for deletion, when the datatype of the proposed replacing property does not even exist yet? Every time we get a new datatype, we often rethink the whole thing of how the datatype can be used. I therefor vote: Hold this PfD until the relevant datatypes are available. -- Lavallen (talk) 08:38, 8 November 2013 (UTC)
I think it is better to have a plan so we avoid too much abortive work. Filceolaire (talk) 16:58, 8 November 2013 (UTC)
The "abortive work" can be modified later by a bot. -- Lavallen (talk) 18:38, 8 November 2013 (UTC)
 Keep, it is more simple manage and use separate properties, then property+qualifier. — Ivan A. Krestinin (talk) 19:38, 8 November 2013 (UTC)
 Keep, it is easier to insert and easier to query לערי ריינהארט (talk) 17:00, 16 November 2013 (UTC)
I think 'Name' is easier to insert and easier to query and easier to manage because you don't need to guess which property has been used on the wikidata page - it's always the 'Name' property. Where more information is available then it can still be included via a qualifier. Filceolaire (talk) 13:26, 27 November 2013 (UTC)
How about a "Designation"-property? I have a set of pages, where the "name" is only a designation. Using a "name"-property will give it more authority than is intended. -- Lavallen (talk) 13:36, 27 November 2013 (UTC)
Insert: How many clicks are needed to insert 'Name' property + 'Short name' qualifier? How many clicks are needed to specify 'Short name' property? Query: that is more simple and more stable: {{#property:P513}} or {{invoke:Wikidata | formatStatements|property=P186|qualifier=P518|qualifiervalue=Q12014132}}? Please give a sample of infobox where you need some name without specifying its type. Manage: How many error types are possible with P513? (I know two: invalid value, invalid domain) How many error types are possible with 'Name' + qualifier? (I know: invalid value, invalid domain, missing qualifier, invalid qualifier property, invalid qualifier value, unexpected qualifier value). How to detect every of these error types? — Ivan A. Krestinin (talk) 20:47, 27 November 2013 (UTC)
 Keep Very useful for queries and for adding sources (that cannot be done with labels). --Paperoastro (talk) 10:18, 8 December 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P206 located on body of water

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. No consensus reached.--Jasper Deng (talk) 03:59, 9 December 2013 (UTC)

located in or next to body of water (P206): (delete | history | links | entity usage | logs | discussion) Superceded by located in/on physical feature (P706).

That sound like the German label and description needs to be rewritten. I think we should be able to use P706 to create a hierarchy from hill to island to lake to subcontinent to ocean to Earth. Filceolaire (talk) 21:12, 6 November 2013 (UTC)
There are two different ways to describe the position of an item relative to a lake, river or hill. See my sketch. In case 1, item A is located on the coast of lake B (or close to hill B). In case 2, the island A is located in lake B (or the village A is located on hill B). These are two fundamental different ways in describing a position and therefore two different properties are needed. --Pasleim (talk) 23:35, 6 November 2013 (UTC)
So P206 needs to be renamed "Located next to terrain feature"? Filceolaire (talk) 22:04, 7 November 2013 (UTC)
Agree with Filceolaire, it would make it easier to explain the differences between these properties in other languages. -- Lavallen (talk) 08:47, 8 November 2013 (UTC)
The English label looks fine now. Should we also copy the image with the explanation and a link to this discussion to Property_talk:P206? --Zuphilip (talk) 10:56, 17 November 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P114

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

No consensus for deletion. John F. Lewis (talk) 21:06, 14 December 2013 (UTC)

airline alliance (P114): (delete | history | links | entity usage | logs | discussion) Merge to member of (P463).--GZWDer (talk) 14:51, 17 October 2013 (UTC)

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

Image 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.

Keep all, at least for the time being. Consensus is pretty clear on not deleting any of these while they are in use on the Wikipedias. --Jakob (Scream about the things I've broken) 00:15, 16 December 2013 (UTC)

Follow Wikidata:Requests for comment/Image properties: many properties or many qualifiers. Per the discussion above, I have make one request per item.

Noticed users voted above:

  1. @Lavallen:
  2. @JAn Dudík:
  3. @Pasleim:
  4. @Ivan A. Krestinin:
  5. @Rschen7754:

--GZWDer (talk) 10:32, 7 December 2013 (UTC)

However, we can not query them by qualifier yet, and that's the reason that Rschen7754, TCN7JM, Paperoastro, Shlomo and Holger1959 oppose these Rfd request.

Therefore, per Rschen7754 and others', I think this discussion might be on hold until bugzilla:47930 is solved. --GZWDer (talk) 11:06, 8 December 2013 (UTC)

  • @GZWDer:: For chemicals, a depicts (P180) could be the structural formula, a 3D model (e.g. ball and stick, or space filling), a photograph of the pure chemical. Hence, I think that you should be specific. Otherwise, we will have one type for some chemicals and another type for others. chemical structure (P117) is also too unspecific. --Leyo 18:27, 8 December 2013 (UTC)
  • One general comment for all of the properties: While using only a "generic" image property (image (P18)) with a qualifier (depicts (P180)) seems more efficient, having separate properties for things like logos, flags, etc. is easier for the user interface, the projects that use the data (infoboxes on Wikipedia, etc.), constraints, and querying, at least for now. The Anonymouse (talk) 06:43, 11 December 2013 (UTC)

route map (P15)

  • this is being used by en, simple, ocwiki.--GZWDer (talk) 10:37, 7 December 2013 (UTC)
    •  Keep Honestly, there was not enough widescale participation in that RFC, with only 8 participants. I see no reason to delete this property, which is already in wide use across three wikis and several items, and is a showcase of what Wikidata can do, as noted in several newsletters. Using qualifiers will make accessing this property much more difficult. --Rschen7754 10:54, 7 December 2013 (UTC)
    •  Keep Nope. Not deleting a property we've already put hard work into deploying across three wikis (well, two wikis, ocwiki articles were mainly created by that one bot a while back). My views are pretty much aligned with Rschen's. TCN7JM 14:54, 7 December 2013 (UTC)
    •  Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties. Ontologically join so different properties to one only because have the same datatype is without sense, for me. In this manner we could use only one properties for datatype and use qualifier to distinguish them! Another question: what about constraints? @Ivan A. Krestinin: now it is possible to use constraint also with qualifiers? --Paperoastro (talk) 10:41, 8 December 2013 (UTC)
    •  Keep Would be okay with a migration to a general "map" property, but a generic image property would add difficulty to use while not adding much utility. —Scott5114↗ [EXACT CHANGE ONLY] 03:13, 13 December 2013 (UTC)

flag image (P41)

See Wikidata:Requests_for_deletions/Archive/2013/Properties/1#Property:P41. we can create items for flag images, and use image (P18) for these items. It is more useful to have a item, because there're a lot of property now can be added to flag items.--GZWDer (talk) 11:05, 7 December 2013 (UTC)
 Keep We can create items for flags, but AFAIK we still have no access to the values of their image (P18) properties from a Wikipedia article connected to the country/region/community/whatever item. As soon as this feature is available, we can (should...) consider moving the flag pictures to a more proper place, but in the meantime please keep the flag picture property at a place accessible from Wikipedias. Otherwise, we would do a great disservice to the Wikipedias who already started using these properties, and especially to the Wikidata supporters there, who - believe me or not - do not always have an easy job.--Shlomo (talk) 19:54, 7 December 2013 (UTC)
    •  Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties. Ontologically join so different properties to one only because have the same datatype is without sense, for me. In this manner we could use only one properties for datatype and use qualifier to distinguish them! Another question: what about constraints? @Ivan A. Krestinin: now it is possible to use constraint also with qualifiers? --Paperoastro (talk) 10:41, 8 December 2013 (UTC)
    •  Keep Having a flag-item with image (P18) and other properties and relating this flag-item by flag (P163) with the main item sounds good, however, first we need a querying tool. Until then, please do not delete it. --Pasleim (talk) 11:51, 8 December 2013 (UTC)
  •  Delete as soon as the technical ability to get the equivalent data on Wikipedias is available, per Pasleim and Shlomo. --Yair rand (talk) 22:55, 10 December 2013 (UTC)

coat of arms image (P94)

signature (P109)

 Question In cs:Šablona:Infobox_rabín the properties P109 and P18 are uesd. If we merge these properties now, is there a way that the infobox will still work? --Pasleim (talk) 11:43, 7 December 2013 (UTC)
In the theory, it can be distinguished by a qualifier (as soon as we have one...). Since all the data required are accessible from the Wikipedia, it should be possible to write a Lua script that will do this job. The only problem is, I'm not that experienced programmer. If you somebody shows me a working example, I'd try to adapt it for the infobox mentioned above.
 Keep Practically, I think that signature image is specific enough data to have it's own property. On the contrary, I'd prefer to create also a "portrait" property for person related items and separate the portrait data from the image (P18) which seems to general to me.--Shlomo (talk) 20:14, 7 December 2013 (UTC)
  •  Keep the given reason for deletion is "this is being used by cswiki". i don't think this is a valid request. Holger1959 (talk) 02:35, 8 December 2013 (UTC)
    •  Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties. Ontologically join so different properties to one only because have the same datatype is without sense, for me. In this manner we could use only one properties for datatype and use qualifier to distinguish them! Another question: what about constraints? @Ivan A. Krestinin: now it is possible to use constraint also with qualifiers? --Paperoastro (talk) 10:41, 8 December 2013 (UTC)

chemical structure (P117)

logo image (P154)

  • this is probably not being used by wiki.--GZWDer (talk) 10:37, 7 December 2013 (UTC)
    •  Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. --Rschen7754 10:55, 7 December 2013 (UTC)
    •  Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties. Ontologically join so different properties to one only because have the same datatype is without sense, for me. In this manner we could use only one properties for datatype and use qualifier to distinguish them! Another question: what about constraints? @Ivan A. Krestinin: now it is possible to use constraint also with qualifiers? --Paperoastro (talk) 10:41, 8 December 2013 (UTC)

seal image (P158)

  • this is probably not being used by wiki.--GZWDer (talk) 10:37, 7 December 2013 (UTC)
    •  Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. --Rschen7754 10:55, 7 December 2013 (UTC)
    •  Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties. Ontologically join so different properties to one only because have the same datatype is without sense, for me. In this manner we could use only one properties for datatype and use qualifier to distinguish them! Another question: what about constraints? @Ivan A. Krestinin: now it is possible to use constraint also with qualifiers? --Paperoastro (talk) 10:41, 8 December 2013 (UTC)

taxon range map image (P181)

  • this is probably not being used by wiki.--GZWDer (talk) 10:37, 7 December 2013 (UTC)
    •  Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. --Rschen7754 10:55, 7 December 2013 (UTC)
    •  Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties. Ontologically join so different properties to one only because have the same datatype is without sense, for me. In this manner we could use only one properties for datatype and use qualifier to distinguish them! Another question: what about constraints? @Ivan A. Krestinin: now it is possible to use constraint also with qualifiers? --Paperoastro (talk) 10:41, 8 December 2013 (UTC)

bathymetry image (P207)

  • this is probably not being used by wiki.--GZWDer (talk) 10:37, 7 December 2013 (UTC)
    •  Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. --Rschen7754 10:55, 7 December 2013 (UTC)
    •  Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties. Ontologically join so different properties to one only because have the same datatype is without sense, for me. In this manner we could use only one properties for datatype and use qualifier to distinguish them! Another question: what about constraints? @Ivan A. Krestinin: now it is possible to use constraint also with qualifiers? --Paperoastro (talk) 10:41, 8 December 2013 (UTC)

locator map image (P242)

  • this is being used by cs, svwiki.--GZWDer (talk) 10:37, 7 December 2013 (UTC)
    •  Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. --Rschen7754 10:55, 7 December 2013 (UTC)
    •  Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties. Ontologically join so different properties to one only because have the same datatype is without sense, for me. In this manner we could use only one properties for datatype and use qualifier to distinguish them! Another question: what about constraints? @Ivan A. Krestinin: now it is possible to use constraint also with qualifiers? --Paperoastro (talk) 10:41, 8 December 2013 (UTC)

astronomic symbol image (P367)

  • this is probably not being used by wiki.--GZWDer (talk) 10:37, 7 December 2013 (UTC)
    •  Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. --Rschen7754 10:55, 7 December 2013 (UTC)
    •  Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties. Ontologically join so different properties to one only because have the same datatype is without sense, for me. In this manner we could use only one properties for datatype and use qualifier to distinguish them! Another question: what about constraints? @Ivan A. Krestinin: now it is possible to use constraint also with qualifiers? --Paperoastro (talk) 10:41, 8 December 2013 (UTC)

orbit diagram (P491)

  • this is probably not being used by wiki.--GZWDer (talk) 10:37, 7 December 2013 (UTC)
    •  Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. --Rschen7754 10:55, 7 December 2013 (UTC)
    •  Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties. Ontologically join so different properties to one only because have the same datatype is without sense, for me. In this manner we could use only one properties for datatype and use qualifier to distinguish them! Another question: what about constraints? @Ivan A. Krestinin: now it is possible to use constraint also with qualifiers? --Paperoastro (talk) 10:41, 8 December 2013 (UTC)

Gene Atlas image (P692)

  • this is probably not being used by wiki.--GZWDer (talk) 10:37, 7 December 2013 (UTC)
    •  Keep The rationale of a RFC that only 8 people participated in as a reason to delete is weak at best. --Rschen7754 10:55, 7 December 2013 (UTC)
    •  Keep there are one-to-one correspondence between these images properties and elements in infoboxes of Wikipedias, as most of the properties. Ontologically join so different properties to one only because have the same datatype is without sense, for me. In this manner we could use only one properties for datatype and use qualifier to distinguish them! Another question: what about constraints? @Ivan A. Krestinin: now it is possible to use constraint also with qualifiers? --Paperoastro (talk) 10:41, 8 December 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P741

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 to delete John F. Lewis (talk) 20:50, 28 December 2013 (UTC)

playing hand (P741): (delete | history | links | entity usage | logs | discussion) Same as above.--GZWDer (talk) 05:24, 18 October 2013 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
@John F. Lewis: 3 votes pro when created (+1 here) vs 3 for deletion here, why to delete? This property should be kept similar to shooting handedness (P423) discussed here
There is problem with values forehand (Q1333285) and backhand (Q1364175) and constraints. --Infovarius (talk) 12:06, 28 September 2014 (UTC)
Consensus is formed in a single discussion. Here there was 3/4 consensus for deletion with arguements that were valid. John F. Lewis (talk) 17:05, 19 November 2014 (UTC)

Property:P992 (function/mission)

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 to delete John F. Lewis (talk) 20:51, 28 December 2013 (UTC)

P992 (P992): (delete | history | links | entity usage | logs) Appears to duplicate the intent of has use (P366). --Izno (talk) 00:30, 19 November 2013 (UTC)

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

Property:P168 (type of structure)

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 to delete John F. Lewis (talk) 20:52, 28 December 2013 (UTC)

P168 (P168): (delete | history | links | entity usage | logs) Some months ago I did use this property frequently to describe the type of building of an item. However, recently I see that instance of (P31) is used also to indicate a type of building, which makes the use of a separate 'type of building' property a kind of confusing duplicate. I don't see any additional value to keep this property as it can be replaced by instance of (P31). I think it is also more user-friendly for future query's to have just one property to describe an item, just use instance of (P31). That the p31 claim is about a type of structure can easily being derived from the target item's building structure subclass. Michiel1972 (talk) 09:40, 21 November 2013 (UTC)

 Delete Move to "instance of" and delete.--Micru (talk) 14:31, 26 November 2013 (UTC)
 Delete. I proposed it, but now it makes no sense with instance of (P31). — Ayack (talk) 16:04, 26 November 2013 (UTC)
 Delete, redundant with instance of (P31) and subclass of (P279). Emw (talk) 13:12, 5 December 2013 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Property:P45

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 to delete John F. Lewis (talk) 20:53, 28 December 2013 (UTC)

P45 (P45): (delete | history | links | entity usage | logs) Grandparent is also non-direct relative. Merge to relative (P1038). And P45 now mix up male or female, paternal or maternal grandparent.--GZWDer (talk) 09:39, 24 November 2013 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Properties_for_deletion/Archive/2013/4&oldid=1576015847"