Wikidata:Properties for deletion/Archive/2015
Contents
- 1 applies to jurisdiction (P1001)
- 2 contains settlement (P1383)
- 3 Datatype change: , , ,
- 4 date of baptism (P1636)
- 5 Datatype change: religious name (P1635)
- 6 category combines topics (P971)
- 7 Property:P1724
- 8 Property:P1722
- 9 Datatype change:
- 10 vessel class (P289)
- 11 Property:P1834
- 12 IPA transcription (P898)
- 13 beats per minute (P1725)
- 14 Property:P1904
- 15 Property:P1131 and Property:P1130
- 16 Properties for events and their dates and locations
- 17 docking port (P546)
- 18 P738 (P738)
- 19 Nova Scotia Register of Historic Places ID (P909)
- 20 architectural style (P149)
- 21 MTR station code (P1377)
- 22 courtesy name (P1782)
- 23 temple name (P1785)
- 24 eligible voters (P1867)
- 25 P1361 (P1361)
- 26 Property:P2022
- 27 Inventari del Patrimoni Arquitectònic de Catalunya code (P1600)
- 28 seal image (P158)
- 29 P1964 (P1964)
- 30 maximum number of players (P1873)
- 31 floruit (P1317)
- 32 name in native language (P1559)
- 33 Property:P2122
- 34 Property:P167
- 35 Property:P1581
- 36 Q21684732
- 37
Property:P659, Property:P857 and Property:P1152 - 38 CWGC burial ground ID (P1920)
- 39 box office (P2142)
- 40 vice-county (P1887)
- Property:P357 replaced by title (P1476)
- Property:P387 replaced by quotation (P1683)
- Property:P392 replaced by subtitle (P1680)
- Property:P438 replaced by inscription (P1684)
- Comment Just a comment like that. It is the supression of the wil create a problem in the constrains in the future? I imagine the property constraint of heritage designation (P1435). The ideal constraint sould be a element sould use location (P276) (for movable property) or located in the administrative territorial entity (P131) (for immovable property). Some immovable property are in heritage district so I used for the location. So how I would now put write constraint without create to much volation? --Fralambert (talk) 23:17, 14 January 2015 (UTC)[reply]
- I have been using to indicate that [museum etc.] is located in [palazzo etc., often. Heritage site] as the inverse for [palazzo] occupant (P466) [museum]. I could use location (P276) for these since museums certainly move from one building to another. - PKM (talk) 23:50, 14 January 2015 (UTC)[reply]
- I am not sure if a museum (the institution, not the building) should be located with first. Maybe it is more a problem of the parameter in the first place Just for looking, Query: claim[131 and claim[1134]] have 6669 claims together (on 8103 items) and Query: claim[131 and claim[276]] only have 474 claims together (on more that 26000 items). So located in the administrative territorial entity (P131) and seem to have a strong use together and located in the administrative territorial entity (P131) and location (P276) a low correlation. --Fralambert (talk) 00:46, 15 January 2015 (UTC)[reply]
- I have been using to indicate that [museum etc.] is located in [palazzo etc., often. Heritage site] as the inverse for [palazzo] occupant (P466) [museum]. I could use location (P276) for these since museums certainly move from one building to another. - PKM (talk) 23:50, 14 January 2015 (UTC)[reply]
Datatype change: religious name (P1635)
edit- The result of the discussion was to keep. --George (Talk · Contribs · CentralAuth · Log) 19:22, 19 March 2015 (UTC)[reply]
category combines topics (P971): (delete | history | links | entity usage | logs | discussion)
As I wrote here at Project Chat, in a broader discussion on the use of is a list of (P360):
I'm going to propose category combines topics (P971) for deletion, because is a list of (P360) is a far better model.
The problem with category combines topics (P971) is that by just specifying that a category combines eg "Paintings" + "London", it gives no way to distinguish whether a category is for "Paintings of London" or for "Paintings in London". It also doesn't specify whether the items in the category are going to be instances of paintings, or instances of Londons -- you have to then check back to the item for painting and the item for London and guess which one is more likely.
Contrast that with how is a list of (P360) handles list of women engineers (Q15832361): it specifies precisely the inclusion criteria, in a form that is natively Wikidata, that precisely corresponds to what would or wouldn't be included on appropriately items. It tells us that the members of this list will have the fundamental nature instance of (P31) human (Q5), that engineer (Q81096) is relevant because it specifies these items' occupation (P106), and that female (Q6581072) is relevant because it specifies these items' sex or gender (P21).
Therefore, particularly @Sjoerddebruin, Multichill:, I hope you won't mind if I nominate category combines topics (P971) for deletion, with a view to migration to is a list of (P360). I think it's the right thing to do.
(As for the point that is a list of (P360) is for "lists", I don't see any value being added by making that particularisation. The way to tell whether something is a list or a category is to look at its P31. What P360 does is to present inclusion criteria, and makes sense to do that with a common syntax on a single common property, whether for lists or for categories)..
See also the further comment I made in the discussion at Project Chat, going into further detail as to how personally I would find P360 on categories far more helpful than P971 when trying to mine categories to boost P31 coverage of items.
--Jheald (talk) 11:15, 26 February 2015 (UTC)[reply]
- Also pinging @GerardM, Casper_Tinan, Pichpich:
- Comment I agree with the general observation that P360 is a better way to map categories than P971. It's not the perfect solution as it seems to know only "AND" not "OR".
Still, there are currently limitations in the way qualifiers can be used by Mediawiki, queries, tools and constraint reports. For that, P971 still has its use. Thus, I'd keep both for now. --- Jura 11:36, 26 February 2015 (UTC)[reply]
- One way to do "OR" would be to allow multiple P360 statements on a category, to show different possible criteria for inclusion. So eg for Category:Spanish Armada (Q8785755) one criterion might be ships that were part of the Armada; one could be people who were commanders of it; another might be events in which it was associated. Not perfect, but not necessarily harder for software to cope with than how we specify multiple children of a mother or father. Further ahead, one could imagine a constraint-violation engine, flagging items included in a particular category (on a given wiki), if they were extraneous to all extraneous to the current inclusion criteria. Jheald (talk) 11:57, 26 February 2015 (UTC)[reply]
- I'd guess GerardM is already doing that. Anyways, we still need both for now. --- Jura 12:05, 26 February 2015 (UTC)[reply]
- So say a bit more, @Jura1: -- what tools or queries or workflows (if any) are you aware of at the moment that use category combines topics (P971) ? I think it would be better, at the very least, to mark it as transitional or deprecated; and to throw a constraint violation if it is used without is a list of (P360) also present. Jheald (talk) 12:09, 26 February 2015 (UTC)[reply]
- Have a look at the constraint reports at category for people born here (P1464) and category for people who died here (P1465). Autolist provides an easy way to list such categories. --- Jura 12:16, 26 February 2015 (UTC)[reply]
- @Jura1: So can constraints not be set to require a particular qualifier rather than a particular value? -- eg "Target item should have is a list of (P360) with qualifier
place of birth (Q1322263)place of birth (P19)" ? Or a particular qualifier-value pair -- qualifier place of birth (P19), value $1 ? Jheald (talk) 12:23, 26 February 2015 (UTC)[reply]
- @Jura1: So can constraints not be set to require a particular qualifier rather than a particular value? -- eg "Target item should have is a list of (P360) with qualifier
- Have a look at the constraint reports at category for people born here (P1464) and category for people who died here (P1465). Autolist provides an easy way to list such categories. --- Jura 12:16, 26 February 2015 (UTC)[reply]
- So say a bit more, @Jura1: -- what tools or queries or workflows (if any) are you aware of at the moment that use category combines topics (P971) ? I think it would be better, at the very least, to mark it as transitional or deprecated; and to throw a constraint violation if it is used without is a list of (P360) also present. Jheald (talk) 12:09, 26 February 2015 (UTC)[reply]
- I'd guess GerardM is already doing that. Anyways, we still need both for now. --- Jura 12:05, 26 February 2015 (UTC)[reply]
- One way to do "OR" would be to allow multiple P360 statements on a category, to show different possible criteria for inclusion. So eg for Category:Spanish Armada (Q8785755) one criterion might be ships that were part of the Armada; one could be people who were commanders of it; another might be events in which it was associated. Not perfect, but not necessarily harder for software to cope with than how we specify multiple children of a mother or father. Further ahead, one could imagine a constraint-violation engine, flagging items included in a particular category (on a given wiki), if they were extraneous to all extraneous to the current inclusion criteria. Jheald (talk) 11:57, 26 February 2015 (UTC)[reply]
- Keep My opinion is that is a list of (P360) and category combines topics (P971) have different purpose and that everything was okay until someone misunderstood one of these properties. I don't see any problem in the current system. Matěj Suchánek (talk) 17:42, 5 March 2015 (UTC)[reply]
- Keep this template can be used to indicate what topics are combined in a category, not how these are combined. We're often not sure. This could be bot populated. Multichill (talk) 19:34, 8 March 2015 (UTC)[reply]
- Keep, P360 is inapplicable for categories. New property for sufficient condition is not created yet. Anyway this is another parallel way for describing category content, not replacement. — Ivan A. Krestinin (talk) 19:29, 10 March 2015 (UTC)[reply]
Sorry. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:18, 26 February 2015 (UTC)[reply]
- Done --Pasleim (talk) 16:22, 26 February 2015 (UTC)[reply]
P1722 (P1722): (delete | history | links | entity usage | logs)
Created in error; sorry. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:18, 26 February 2015 (UTC)[reply]
- Done --Pasleim (talk) 16:23, 26 February 2015 (UTC)[reply]
Datatype change:
editCreated with wrong datatype; sorry Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:22, 19 April 2015 (UTC)[reply]
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.
- Done by Matěj Suchánek. Jianhui67 (talk) 16:01, 10 June 2015 (UTC)[reply]
P1904 (P1904): (delete | history | links | entity usage | logs)
Wrong datatype, sorry Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:38, 27 May 2015 (UTC)[reply]
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.
- Done -- Bene* talk 19:33, 26 June 2015 (UTC)[reply]
P1131 (P1131): (delete | history | links | entity usage | logs)
P1130 (P1130): (delete | history | links | entity usage | logs)
Both properties are only used once and way too specific to the sport. Perhaps a combination of Property:P166 and Property:P1114 as qualifier will suffer and reduce the amount of redundant properties. Another option would be to create a general property "number of victories" or so which then can also be used for other sports.
Pinging User:Kompakt and User:Jakec who proposed/created both. --Bene* talk 15:14, 24 April 2015 (UTC)[reply]
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 keep these properties. Bold to do it, and in addition the requesters was indefinitely blocked as sockpuppets.--GZWDer (talk) 19:04, 26 June 2015 (UTC)[reply]
Similar to
- Wikidata:Requests for deletions/Archive/2014/Properties/1#Taxonomic rank properties and
- the replacement of domain-specific type properties with instance of (P31) and subclass of (P279)
this is a proposal to unify properties with the goal of
- increasing the ability to describe items,
- facilitating data access and presentation,
- increasing the availability of information in multiple languages
- reduce cultural bias.
All values stored by "Date of <event type>"-properties can be described using "Property:P793 significant event". As it seems all of the event types listed below, e.g. "date of birth" would qualify as significant. A qualifier links to the item that describes the type of event and another qualifier links to the item that describes location. If there is a specific item for that event, then this can be linked, and the qualifiers are left empty since date and location can be stored at the event dedicated item.
If all significant events are stored in that way, they could be easily sorted in chronological order, which could help User:Magnus Manske with the Reasonator and WMDE under User:Lydia Pintscher (WMDE) with the Wikidata:UI redesign.
Instead of translating labels and descriptions of items that are event types and also translating these for properties, the latter will not be needed anymore.
Also the current "date of birth" is culturally biased, see en:Bardo#Six bardos in Tibetan Buddhism and IIRC there are people that place the start of existence of a human at the day the parents thought about having (this) child.
Thanks a lot to User:Pasleim for maintaining Wikidata:Database reports/List of properties/all. This was a great help in collecting the properties.
Not included
editProperties with data type = time, which are not proposed for deletion here:
- P1249 date of earliest written record
- P1317 floruit
- P580 start date
- P582 end date
- P585 point in time
Andrea Shan (talk) 09:05, 5 December 2014 (UTC)[reply]
- I added P1317 floruit to those that could be deleted. Frank Robertson (talk) 14:07, 13 December 2014 (UTC)[reply]
List of event classes and related properties
editThese can all be described via significant event (P793). Many event types already use P793, see some listed at Property talk:P793#Rules.
Domain | Event class | Time property (generic) |
Time property (specialized) - number |
Time property (specialized) - English name |
Time property (specialized) - creator |
Location property (generic) |
Location property (specialized) - number |
Location property (specialized) - English name |
Location property (specialized) - creator |
Other property (generic) |
Other property (specialized) |
---|---|---|---|---|---|---|---|---|---|---|---|
Person | parturition (Q3335327) | point in time (P585) | 569 | time of birth | User:Tpt | location (P276) | P19 | place of birth | |||
Person | death (Q4) | point in time (P585) | 570 | time of death | User:Tpt | location (P276) | P20 | place of death | has cause (P828), has immediate cause (P1478) | P509 cause of death, P1196 manner of death | |
Person | burial (Q331055) | point in time (P585) | location (P276) | P119 | place of burial | ||||||
foundation or creation | point in time (P585) | 571 | time of foundation or creation | User:John F. Lewis | location (P276) | P740 | formation location/ place of foundation | ||||
Biology | taxon name publication | point in time (P585) | 574 | time of taxon name publication | User:John F. Lewis | ||||||
discovery (Q753297) | point in time (P585) | 575 | time of discovery | User:John F. Lewis |
|
|
|||||
dissolution (Q18603731) | point in time (P585) | 576 | time of dissolution | User:Delusion23 | |||||||
publication | point in time (P585) | 577 | time of publication | User:Snipre | P291 | place of publication | |||||
Aircraft | maiden flight (Q1362364) | point in time (P585) | 606 | time of first flight | User:Joshbaumgartner | start location? end location? | |||||
Spacecraft | space launch (Q7572593) | point in time (P585) | 619 | time of spacecraft launch | User:Ivan A. Krestinin | location (P276) | P448 | launch site | |||
Space craft | landing (Q844947) | point in time (P585) | 620 | time of spacecraft landing | User:Docu | location (P276) | P1158 | landing site | |||
Spacecraft | Q18603851 | point in time (P585) | 621 | time of spacecraft decay | User:Docu | ||||||
Spacecraft | spacecraft docking/undocking | point in time (P585) | 622 | time of spacecraft docking/undocking | User:Docu | ||||||
service entry | point in time (P585) | 729 | time of service entry | User:John F. Lewis | |||||||
service retirement | point in time (P585) | 730 | time of service retirement | User:John F. Lewis | |||||||
Person | disappearance (Q18603733) | point in time (P585) | 746 | time of disappearance | User:Nightwish62 | ||||||
retrieval | point in time (P585) | 813 | time of retrieval | User:Ajraddatz | |||||||
first performance | point in time (P585) | 1191 | time of first performance | User:Jakec | |||||||
Person | "flourishing" | point in time (P585) or start time (P580) and end time (P582) | 1317 | floruit | User:Jakec | P937 | work location | ||||
official opening | point in time (P585) | 1619 | time of official opening | User:Tobias1984 | P542 officially opened by | ||||||
Person | baptism (Q35856) | point in time (P585) | 1636 | time of baptism | User:Ayack | ||||||
Film | filming | point in time (P585) or start time (P580) and end time (P582) | P915 | filming location | |||||||
Manufactured item | assembly/production | point in time (P585) or start time (P580) and end time (P582) | location (P276) | P1071 | place made/assembly location, place built | manufacturer | |||||
journey | start location? | P1427 | journey origin/ starting place of this journey | ||||||||
Company/commune/country | change of ownership (Q14903979) | point in time (P585) | 'from', 'to' | ||||||||
Company/commune/country | name change (Q14904150) | point in time (P585) | 'from', 'to' | ||||||||
Company/commune/country | corporate spin-off (Q15865002) | point in time (P585) | |||||||||
Company/commune/country | union (Q17853087) | point in time (P585) | |||||||||
Person | amputation (Q477415) | point in time (P585) | |||||||||
Person | funeral (Q201676) | point in time (P585) | location (P276) | ||||||||
Person | drafting | P647 drafted by | |||||||||
Creative work | première (Q204854) | ||||||||||
Building/infrastructure/monument | groundbreaking ceremony (Q1068633) | point in time (P585) | |||||||||
Building/infrastructure/monument | cornerstone (Q1133673) | point in time (P585) | |||||||||
Building/infrastructure/monument | construction (Q385378) | start time (P580), end time (P582) | |||||||||
Building/infrastructure/monument | topping out (Q1075723) | point in time (P585) | |||||||||
Building/infrastructure/monument | inauguration (Q1417098) and/or dedication (Q1762010) and/or consecration (Q125375) | point in time (P585) | |||||||||
Building/infrastructure/monument | opening (Q15051339) | point in time (P585) | |||||||||
Building/infrastructure/monument | renovation (Q2144402) | start time (P580), end time (P582) | |||||||||
Building/infrastructure/monument | closure (Q14954904) | point in time (P585) | |||||||||
Building/infrastructure/monument | demolition (Q331483) | point in time (P585) | |||||||||
Building/infrastructure/monument | reopening (Q16571590) | point in time (P585) | |||||||||
Building/infrastructure/monument | relocation (Q2918584) | point in time (P585) | start location?, end location? | ||||||||
Building/infrastructure/monument | destruction (Q17781833) | start time (P580), end time (P582) | has cause (P828) | cause of destruction (P770) this qualifier is important for accidental destruction not for planned demolition. | |||||||
Car/plane/Computer/item | presentation (Q604733) | point in time (P585) | location (P276) | ||||||||
Car/plane/Computer/item | production (Q739302) (see Production or distribution ?) | start time (P580), end time (P582) | location (P276) | ||||||||
Ship | order (Q566889) | point in time (P585) | |||||||||
Ship | keel laying (Q14592615) | point in time (P585) | |||||||||
Ship | ship launching (Q596643) | point in time (P585) | |||||||||
Ship | shipbuilding (Q474200) | end time (P582) | |||||||||
Ship | ship commissioning (Q14475832) | point in time (P585) | |||||||||
Ship | destruction (Q17781833) | start time (P580), end time (P582) | location (P276) | has cause (P828) | cause of destruction (P770) is important for accidental destruction, not for planned demolition. | ||||||
Ship | ship decommissioning (Q7497952) | point in time (P585) | location (P276) | ||||||||
Ship | retirement (Q946865) | point in time (P585) | location (P276) | ||||||||
Ship | ship disposal (Q7497950) | point in time (P585) | |||||||||
Ship | scuttling (Q1786766) | point in time (P585) | |||||||||
Ship | ship breaking (Q336332) | start time (P580), end time (P582) | location (P276) | ||||||||
Wealth | donating | P1028 donated by | |||||||||
oathing | P543 oath made by | ||||||||||
lighting a torch | P545 torch lit by | ||||||||||
Person | nominating for an award | P1411 nominated for | |||||||||
Geography | claiming a territory | P1336 territory claimed by | |||||||||
Something | using something | P1535 used by | |||||||||
Theory | proving | P1318 proved by | |||||||||
Person | ordination of a bishop/consecration | P1598 consecrator | |||||||||
Manufactured item | printing | P872 printed by | |||||||||
Statement | disputing a statement | P1310 disputed by | |||||||||
Question | solving a question | P1136 solved by | |||||||||
Statue ... | unveiling | P1656 unveiled by | |||||||||
Person | education (Q8434) | location (P276) | 69 | educated at | P1066 student of |
Discussion
editComment @Andrea Shan: With this system, how would you specify the type of relation between the item and the event ? For instance, a birth is a significant event for both the mother and the newborn. How would I know who is who ? How would I be able to query this information ? Will a query about women born in 1950 also return the list of women that gave birth that year ? --Casper Tinan (talk) 10:13, 5 December 2014 (UTC)[reply]
- Good point, I hoped there would be a solution and maybe there is: At Q320, a woman, has several significant events with item "childbirth (Q34581)". So the event as seen from the child could use "birth", or an extra item is created for that. Alternatively one could use "role=mother" on the mother page and "role=child" on the child page, then there is also no more need for defining the natural mother in another property. Andrea Shan (talk) 10:40, 5 December 2014 (UTC)[reply]
- Your first proposal implies having two items to describe a single event. It is strictly impractical. The second one would work provided we are able to query qualifiers, which would not be the case before a long time. Casper Tinan (talk) 12:55, 5 December 2014 (UTC)[reply]
- Casper Tinan The first proposal is already in use. Mothers don't use "birth". One can use "birth" on the child item and the date would be, when the item is born. If "birth" is used on the mother site, then in her role as a child. Andrea Shan (talk) 13:03, 5 December 2014 (UTC)[reply]
- @Andrea Shan:I was making the assumption that significant event (P793) would be used to link items to instances of events, as it is suggested in the property's label, rather than to classes of events. With the current practice, you have to enter twice the information (date, location) about the birth and if there is an error, you have to correct the two statements, which are not directly linked. And it is worse with events with more participants such as a rugby union international match, which may be the first international match of some players, the last for some others and the largest victory of the winning team. Casper Tinan (talk) 18:53, 5 December 2014 (UTC)[reply]
- Casper Tinan The first proposal is already in use. Mothers don't use "birth". One can use "birth" on the child item and the date would be, when the item is born. If "birth" is used on the mother site, then in her role as a child. Andrea Shan (talk) 13:03, 5 December 2014 (UTC)[reply]
- Your first proposal implies having two items to describe a single event. It is strictly impractical. The second one would work provided we are able to query qualifiers, which would not be the case before a long time. Casper Tinan (talk) 12:55, 5 December 2014 (UTC)[reply]
- Keep: now that we can added statements to properties, the mapping can be added there and the above properties kept.
- Besides, qualifiers can't be queried in the near and distant future. Thus the way to go should be make specific properties rather than to attempt to use a single property for everything. --- Jura 11:58, 5 December 2014 (UTC)[reply]
- You seem to ignore
- the translation issue
- that with keeping some event-type-specific properties, and at the same time keeping "significant event" there are two systems, by adopting the proposal there would only be one
- the maintenance issue, creating an unknown number of event specific properties, each as date and as location.
- the expressiveness issue and cultural bias issue - normal users cannot create designated properties and if they don't think that something like "significant event" exists, because on many pages the specific properties are used, then they may feel uncomfortable.
- If qualifiers "can't be queried" then it would not be possible they are displayed. Maybe you mean via API. Then this should be fixed ASAP. Andrea Shan (talk) 12:14, 5 December 2014 (UTC)[reply]
- @Andrea Shan: Developer said «Querying for sources or qualifiers not to be done». I don't know the reason (technical feasibility or resource). --ValterVB (talk) 20:15, 5 December 2014 (UTC)[reply]
- For the other points mentioned by Andrea, it seems that I might as well ignore them as they can apply also to the solution proposed by Andrea. An exception might be a "Translation issue", as I don't understand what that may be in this context. --- Jura 07:37, 6 December 2014 (UTC)[reply]
- @ValterVB. Qualifies can be queried in the current API: we can use the qualifiers to filter data. So for the step 2 of wikidata developement, for the infoboxes or text query, there is no problem. The problem of the development is to define a tool for the query of lists. So if it is possible to query for one person its birth date stored with significant event (P793), it is not forseen to do the same to extract a list of all persons born in 1980 for example. There is no technical difficulty but only a two steps process to develop because filtering with qualifiers implies first to get a list of items corresponding to a certain parameter (all person item with a birth date value) and then to filter again that list with a second parameter (all person item with a birth date equals to 1980). Snipre (talk) 11:53, 6 December 2014 (UTC)[reply]
- Of course, I was referring to the creation of lists. For single item no problem, we already use on it.wiki with Lua. Sorry for misunderstanding and thanks for the explanation --ValterVB (talk) 12:49, 6 December 2014 (UTC)[reply]
- @ValterVB. Qualifies can be queried in the current API: we can use the qualifiers to filter data. So for the step 2 of wikidata developement, for the infoboxes or text query, there is no problem. The problem of the development is to define a tool for the query of lists. So if it is possible to query for one person its birth date stored with significant event (P793), it is not forseen to do the same to extract a list of all persons born in 1980 for example. There is no technical difficulty but only a two steps process to develop because filtering with qualifiers implies first to get a list of items corresponding to a certain parameter (all person item with a birth date value) and then to filter again that list with a second parameter (all person item with a birth date equals to 1980). Snipre (talk) 11:53, 6 December 2014 (UTC)[reply]
- You seem to ignore
- Comment We can't add source to qualifier. So if I have a source for "date of birth" and a different source for "place of birth", how we can manage? Another example is "start date" and "end date" for "marriage". --ValterVB (talk) 08:48, 14 December 2014 (UTC)[reply]
- That means all statements in qualifiers are without source? Could that be a severe shortcoming of the software? One could create two claims for birth, the first with a date and the related sources, the second with the place and the related sources. Currently if there are differing claims for time (T1, T2) and location (L1, L2) the claims are spread and hard to connect. Maybe in reality all sources either claim T1+L2 or T2+L1 are correct. Either he died at 9:05 in the entrance of the building or 9:15 in his room. Aren't there also different kinds of death, clinical death (clinical death (Q1989450)), brain death (brain death (Q223867)), legal death? So, would one create date of clinical death, date of brain death, date of legal death and location of clinical death, location of brain death, location of legal death? And another set for "cause" ... cause of clinical death, cause of ... It seems specialized time of/date of properties simply don't scale. Frank Robertson (talk) 12:10, 14 December 2014 (UTC)[reply]
- That means all statements in qualifiers are without source? Could that be a severe shortcoming of the software? One could create two claims for birth, the first with a date and the related sources, the second with the place and the related sources. Currently if there are differing claims for time (T1, T2) and location (L1, L2) the claims are spread and hard to connect. Maybe in reality all sources either claim T1+L2 or T2+L1 are correct. Either he died at 9:05 in the entrance of the building or 9:15 in his room. Aren't there also different kinds of death, clinical death (clinical death (Q1989450)), brain death (brain death (Q223867)), legal death? So, would one create date of clinical death, date of brain death, date of legal death and location of clinical death, location of brain death, location of legal death? And another set for "cause" ... cause of clinical death, cause of ... It seems specialized time of/date of properties simply don't scale. Frank Robertson (talk) 12:10, 14 December 2014 (UTC)[reply]
P19 and P20 on Einstein page with claims about location of the location:
- http://www.wikidata.org/w/index.php?title=Q937&oldid=182304814#P19 claims about Ulm
- http://www.wikidata.org/w/index.php?title=Q937&oldid=182304814#P20 claims about Princeton
91.9.127.22 15:57, 22 December 2014 (UTC)[reply]
- @ValterVB, Jura1, Andrea Shan: The new query tool integrates qualifiers in the search. See the documentation here. This is available in the last weekly summary. Snipre (talk) 17:00, 22 December 2014 (UTC)[reply]
- This isn't for the same functions. --- Jura 18:32, 23 December 2014 (UTC)[reply]
- Jura Sorry I don't understand your remark: we don't need the same function, who was asking that ? The only question is can we query value using qualifiers and the answer is yes. We don't have the same functions for time or coordinates values and this is not a problem.. Snipre (talk) 13:34, 25 December 2014 (UTC)[reply]
- This isn't for the same functions. --- Jura 18:32, 23 December 2014 (UTC)[reply]
- Keep I can change my opinion when we will can add source to qualifiers. --ValterVB (talk) 19:34, 23 December 2014 (UTC)[reply]
- ValterVB You don't need to be able to add sources to qualifiers: you can add several statements for the same event like birth with each time a different qualifier and the corresponding source. Snipre (talk) 13:28, 25 December 2014 (UTC)[reply]
- ValterVB By the way how can you describe several marriages with the current system (2 marriages with two different persons at different dates and different locations) ? Only the qualifiers system can solve this problem. Snipre (talk) 13:28, 25 December 2014 (UTC)[reply]
- @Snipre: Like in Elizabeth Taylor (Q34851). See at spouse (P26) I can add a source for every spouse. --ValterVB (talk) 17:11, 25 December 2014 (UTC)[reply]
- @ValterVB: So why can't you do the same with significant event property ? The spouse property is similar to significant event and use qualifiers to provide more information and sources. And how do you specifiy the marriage locations for all these marriages ? Snipre (talk) 20:40, 25 December 2014 (UTC)[reply]
- @Snipre: Like in Elizabeth Taylor (Q34851). See at spouse (P26) I can add a source for every spouse. --ValterVB (talk) 17:11, 25 December 2014 (UTC)[reply]
- Comment In that radical generality of the proposal Wikidata does need almost no properties at all: Just one for each datatype and compounds of it (like (time interval X place one X place two) for "events"), anything else is dealt with by qualifiers derived from Q-items. Also part of the discussion here is about the feasibility (and desirability) of a dedicated event data type: It would keep places and dates closer together for the price of loosing the ability to hold qualifiers for the "atomic" constituents (like source statements). For many existing properties then it is open to discussion whether they are two singular events involved at the start rsp. end of an interval (like birth/death, vernissage/finissage) or rather one event (life, exhibition): Seems to depend on the point of view but for the sake of the data model one should stick to one of the possibilities... -- Gymel (talk) 10:09, 24 December 2014 (UTC)[reply]
- Gymel you don't understand the problem of the event items: event can be defined by time, location, persons, actions,... All these characteristics have to be linked together. So if this can be done by the event name like for birth which occurs only once, in case of marriage this system can't work. You can have different marriages with different marriage locations. Only statements with qualifiers can handle these cases so we have to focus on this system. Then can we work with two systems one using qualifiers and the second using several properties ? No so best is to work with only the qualfier system. Snipre (talk) 13:28, 25 December 2014 (UTC)[reply]
- Sure I see the limits of single, unqualified properties for non-unique events. However it is the question whether a "married-to" property qualified by a point of time (or an interval) and whatever one deems important (location, ...) is more desirable or an "significant event" property qualified by a generic "type of event" with Q-item "marriage": The proposal taken to the extreme ends up with a version of wikidata with very few generic properties in alignment with datatypes plus a handful generic properties for use as qualifiers and the "semantic flesh" is shifted from properties to q-items as objects of generic properties. This definitely would be even more flexible but I think very different from the original design of wikidata. -- Gymel (talk) 19:31, 25 December 2014 (UTC)[reply]
- Gymel It is not a question of small amount of properties or big amount of properties. It is a question of structuring data which are together using a way to connect them together. If you create two single properties for birth date and birth location, how do you connect these two properties which are elements of the same event ? You will have to specify somewhere in your system that these two properties are related. The problem is the connection bewteen data related to the same topic. And the only way to solve this is the qualifier system. It is not a choice, this is currently the only way to link data about the same event. And if the case of the birth or the death is simple, the case of the marriage shows the limits of the all properties system: if a event can occur several times you have to multiply the properties. Just a pratical example: one person is getting married 2 times, one event occuring several times. I don't want to discuss about what should be wikidata or was the original design of wikidata. I just want from you your explanations about how to model these data:
- Q item: John Doe
- statement 1: marriage with Calamity Janes in Paris the 2. February 2004. Divorced the 23. March 2007
- statement 2: marriage with Mini Mouse in London the 15. June 2009.
- Snipre (talk) 20:21, 25 December 2014 (UTC)[reply]
- There are many possibilities and I do not have a preference there:
- a marriage-as-punctual-event property with the spouse as value and qualifiers for date and place plus an annotation for the "corresponding" divorce
- a marriage-as-period-of-time property with a time interval and corresponding points in space for the temporal endpoints and a qualifier for the type of termination
- the foregoing marriage properties qualified by values of a compound point-in-space-time or path-in-space-time datatype (taking values of eg. (London; 15. June 2009) or ((Paris; 2. February 2004) .. (unknown; 23. March 2007))
- a generic "significant-event" property with one or several properties as above for the corresponding space-time coordinates and a qualifier for "marriage" as the type of event. In natural language this would correspond to reducing the number of verbs in favor of adverbial or passivic constructions (attributes of bureaucratic language)
- similar to exhibitions as "institutionalized events" a q-item for any single marriage carrying "ordinary" properties for start and end points, locations and the persons involved (this may be the only solution which can be extended to polyamourous group marriages?). This is not as absurd a construction as it might first seem, cf. en:Presidency of Bill Clinton, an "event" which coupled the person Bill Clinton and the U.S. Government or the United States for a certain interval in time. We might borrow the notion of "reification" for this approach.
- I still think we are dealing with two rather distinct questions here: How to cope with non-atomic data types (like the coupling of place and date with the additional difficulty of recording individual sources or annotations for each of the atoms) and about specific properties vs. very generic ones "typed" by q-items (you can express anything you want without introducing new properties but successful querying might more than before depend on rigorous and exhaustive subclass-relations on the space of q-items). -- Gymel (talk) 22:11, 25 December 2014 (UTC)[reply]
- There are many possibilities and I do not have a preference there:
- Gymel It is not a question of small amount of properties or big amount of properties. It is a question of structuring data which are together using a way to connect them together. If you create two single properties for birth date and birth location, how do you connect these two properties which are elements of the same event ? You will have to specify somewhere in your system that these two properties are related. The problem is the connection bewteen data related to the same topic. And the only way to solve this is the qualifier system. It is not a choice, this is currently the only way to link data about the same event. And if the case of the birth or the death is simple, the case of the marriage shows the limits of the all properties system: if a event can occur several times you have to multiply the properties. Just a pratical example: one person is getting married 2 times, one event occuring several times. I don't want to discuss about what should be wikidata or was the original design of wikidata. I just want from you your explanations about how to model these data:
- Sure I see the limits of single, unqualified properties for non-unique events. However it is the question whether a "married-to" property qualified by a point of time (or an interval) and whatever one deems important (location, ...) is more desirable or an "significant event" property qualified by a generic "type of event" with Q-item "marriage": The proposal taken to the extreme ends up with a version of wikidata with very few generic properties in alignment with datatypes plus a handful generic properties for use as qualifiers and the "semantic flesh" is shifted from properties to q-items as objects of generic properties. This definitely would be even more flexible but I think very different from the original design of wikidata. -- Gymel (talk) 19:31, 25 December 2014 (UTC)[reply]
- Gymel you don't understand the problem of the event items: event can be defined by time, location, persons, actions,... All these characteristics have to be linked together. So if this can be done by the event name like for birth which occurs only once, in case of marriage this system can't work. You can have different marriages with different marriage locations. Only statements with qualifiers can handle these cases so we have to focus on this system. Then can we work with two systems one using qualifiers and the second using several properties ? No so best is to work with only the qualfier system. Snipre (talk) 13:28, 25 December 2014 (UTC)[reply]
- Delete per Snipre
- data related: 1) 13:28, 25 December 2014 2) 20:21, 25 December 2014 the marriage example - significant-event is the only way to connect properties (location, time, participants) of events of a type that can occur several times.
- tool related: 1) 17:00, 22 December 2014 - new query tool
- WK7489 (talk) 12:35, 28 December 2014 (UTC)[reply]
Comment Qualifiers allow you to attach statements to another statement (the base claim). Think of this as a graph edge, with an anonymous (blank) node in the middle of it: qualifiers make statements against this blank node. But they can do this only 1-level deep. There may be situations when we need to go deeper, eg:
- different source statements for different aspects of the same event (blank node)
- statements about different authors and dates of handwriting on the same page of a manuscript (if it's significant they're on the same page)
From this point of view, qualifiers are neither necessary, nor sufficient approach to modeling general graphs. (Which doesn't mean I think they are not useful!) Being something of an ontology engineer, I like the more generic approach proposed in this section. On the other hand, ithas practical considerations, eg:
- RDF export of qualified claims is much more complicated. "Introducing Wikidata to the Linked Data Web" fig3 shows the complex (read "ugly") way in which qualifiers are reified. We're currently using the "simple export" that doesn't export qualified claims, and not yet considering the full export.
- Validation gets more complex, eg "birth should be before death" or "floruit is applicable only to Human".
The Getty person thesaurus (ULAN) has a structure "Event", nevertheless it treats birth&death date&place separately. I guess that's for pragmatic reasons: we want most persons to have recorded birth&date, while the Events are optional ("nice to have"). Overall, I think I support the proposal, but I think the decision is far from simple. --Vladimir Alexiev (talk) 10:12, 25 January 2015 (UTC)[reply]
Idea to merge all properties to single sound good in theory. But real practice showed that too generic properties have tendency to become unstructured heap of strange claims. For example station code (P296) or coordinate location (P625). So my position is Keep individual properties and think about deleting significant event (P793). Also this discussion is needed to be speedy closed by formal reason: steps declared in this page header was not executed. — Ivan A. Krestinin (talk) 20:14, 1 February 2015 (UTC)[reply]
- @Ivan A. Krestinin: And how do you connect several properties about the same event ? The typical case: two mariages with two different partners at two different locations. You can use twice the marriage date property, twice the partner property and twice the marriage location property. And to be able to know which was the husband of the first marriage and its location you have to perform complex analysis of date to find all informations about one event. The conclusion is simple: when two properties or more are necessary to describe one event we should use only the significant event (P793) property.
- And before saying thing like "deleting significant event (P793)", just try to write a solution for cases like this one. Snipre (talk) 14:42, 7 April 2015 (UTC)[reply]
- Current structure mixes two different entities: marriage as event (1-3 days long, with concrete location) and marriage as process (many years relation, without specific location). Another variant: [1]. — Ivan A. Krestinin (talk) 20:54, 7 April 2015 (UTC)[reply]
- If your solution presents some pratical interest, it is completely illogical: how can you associate dates and location to a person ? Spouse property is a person property and this solution will be a mess later when we will develop automatic tools to validate and to check data consistency. We are speaking about an event (mariage) so the minimum is to create an event property. Snipre (talk) 19:24, 8 April 2015 (UTC)[reply]
- Current structure mixes two different entities: marriage as event (1-3 days long, with concrete location) and marriage as process (many years relation, without specific location). Another variant: [1]. — Ivan A. Krestinin (talk) 20:54, 7 April 2015 (UTC)[reply]
- Delete. We will never be able to foresee all the specific properties for all fields of the knowledge. Therefore significant event (P793) offers great flexibility to use existing elements (example ; example), with the possibility to use start time (P580) and end time (P582) or just point in time (P585), and at the condition to be a subclass of occurrence (Q1190554). So we should stop creating scores of specific properties whose the future querries will struggle to find the meaning. Also, the content of significant event (P793) is now included in some prototypes of Lua infoboxes in WP:fr and it is working well. Louperivois (talk) 21:44, 26 April 2015 (UTC)[reply]
- Keep Now that we can make statements about properties we can label all properties related to significant events as "subproperty of (P1647):significant event (P793)" so you can get all these events by searching on P793 plus subproperties. This means that having rather obscure properties will be less of a problem once we can do this kind of search.
- P793 also has a big problem in that it is used to link to generic items like marriage, topping out, ship launching (each a class of event) and it is also used to items for specific events like the various battles that make up a war. For generic events the date, location etc. is stored as qualifiers in the 'significant event' statement but for specific event items these are stored in the item linked to. It is hard to be consistent when we have these two very different use cases. Filceolaire (talk) 19:41, 1 May 2015 (UTC)[reply]
- Keep: We would have the same effect that we have with instance of (P31) where have everything and anything. Because instance of (P31) is not specific enough to have a real meaning. So at the end, this property can't be used.
And I don't speak of subclass of (P279). So first try to work on instance of (P31) before trying to suppress properties that every one can understand. --Dom (talk) 14:07, 6 June 2015 (UTC)[reply]
- Keep. mark these properties as subproperty of (P1647):significant event (P793). One day, when we have a 'Search (including subproperties)' function I will be proposing that P793 should only be used to link to specific event items (each battle in a campaign, each eruption of a volcano etc.) and that all links to generic class of events be replaced with specific properties. Filceolaire (talk) 20:47, 18 June 2015 (UTC)[reply]
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. docking port (P546): (delete | history | links | entity usage | logs | discussion) Discussion for the property creation
Existing since May 2013 but still not used.
- Keep. Property talk:P546 defines clearly the notion, and indicates this is an infobox field.
- The main goal is to note the docking port of spaceships. The example given during the discussion were Soyuz TMA-9 first docking port is the Zvedza ISS module. I've added it, so we have a working example.
- A similar property is the home port. So we can describe regular traject from home port to docking port with these two properties. --Dereckson (talk) 09:59, 11 September 2014 (UTC)[reply]
- See also spacecraft docking/undocking date (P622), which is more used. So we have the date and the location. --Dereckson (talk) 17:42, 13 September 2014 (UTC)[reply]
- Delete "docking port" (P:P546): @Dereckson: unless there are at least 5 uses, I'd delete this. --- Jura 13:28, 30 November 2014 (UTC)[reply]
Keep I'll add more --Adert (talk) 19:07, 16 June 2015 (UTC)[reply]
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. Before statements get removed, templates using this property need to be adjusted. --Pasleim (talk) 09:52, 11 August 2015 (UTC)[reply]
P738 (P738): (delete | history | links | entity usage | logs) This property is a clear reversed duplicate of influenced by (P737) (and is actually stated to be so). Besides it is impossible to manage in a good number of cases: while a person can only be influenced by a limited number of people during his/her whole lifetime, the reverse is not true, and some influential thinkers can have a wide number of followers. Listing all the items influenced by Plato (Q859) or Jesus (Q302) is going to be a major headache. Alexander Doria (talk) 17:16, 12 December 2014 (UTC)[reply]
- Lean keep. Alexander, what you label a "reversed duplicate" is typically called an "inverse". These are often useful and widespread on the Semantic Web. I wouldn't lead an argument for deletion with that rationale.
- Your point about the huge number of potential claims that could be made with this property is worth considering, though. Adding each philosopher influenced by Plato to Plato (Q859) via influence of would clearly be a bad idea. However, I think looking at Plato's infobox in various Wikipedias indicates a possible solution to that problem:
-
- Influenced by: Socrates, Homer, Hesiod, Aristophanes, Aesop, Protagoras, Parmenides, Pythagoras, Heraclitus, Orphism
- Influence of: Most of Western philosophy (Q842333) that came after his works
-
-
- Influenced by: Pre-Socratic philosophy, Socrates, Greco-Roman mysteries, Orphism
- Influence of: Much of Western philosophy; part of Islamic philosophy (Q193104)
-
-
- Influenced by: Socrates, Archytas, Democritus, Parmenides, Pythagoras, Heraclitus
- Influence of: Aristotle, almost all European and Middle Eastern philosophers
-
- In other words, for very influential things, simply have the value of influence of be a movement of which their influencees were a part. Then if we want to do inference down the road, we could look up or deduce the influencee's movement (P135) (or what have you), and infer that the influencer satisfies a large number of more specific influence of claims. Emw (talk) 01:15, 13 December 2014 (UTC)[reply]
- I really don't see the need for an inverse (and I have already seen several successful PfD done on this ground). The WikidataQuery API already allows to do the exact same thing using influenced by (P737) : you can retrieve all the philosophers that claims to be influenced by Plato. We are merely doing the same work twice.
- And I'm unconvinced by your solution: Most of Western philosophy is quite fuzzy. There are actually numerous influential western philosophical movements that do not claim an influence from Plato (Epicureanism, Cartenianism, Positivism…). It's really more suitable to only use influenced by (P737) and get all the results in a reverse way.
- Alexander Doria (talk) 11:49, 13 December 2014 (UTC)[reply]
- Wikipedia cannot use Wikidataquery to display info. Note that some widely used infoboxes like en:Template:Infobox scientist contain "influenced" fields. fr:Module:Infobox/Philopsophe makes use of this property as a default, though so far with no hits (fr:Catégorie:Page utilisant des données de Wikidata/P738).
- When an item is not a "big influencer" (say, is p737 value in less than 10 items), a bot should update it automatically. When there are many potential values, I am not too sure what to do.--Zolo (talk) 13:09, 13 December 2014 (UTC)[reply]
- Keep: If we were to get rid of this, then we would have to get rid of Parent or Child, as these can also be considered inverse properties. Staple of data in my mind. Hazmat2 (talk) 15:32, 27 April 2015 (UTC)[reply]
- And we should (get rid of child in this case). That parent has been allowed to survive is... a problem. :) --Izno (talk) 21:44, 1 May 2015 (UTC)[reply]
- You made my day. Hazmat2 (talk) 03:19, 2 May 2015 (UTC)[reply]
- Delete. This is clearly a property that should be deleted because of problems regarding citeability and scope. And to be honest, it's not important to the person who is doing the influencing; only the person who is influenced. --Izno (talk) 21:44, 1 May 2015 (UTC)[reply]
- I agree. Delete. --Yair rand (talk) 20:36, 21 July 2015 (UTC)[reply]
- Delete Use only influenced by (P737). --- Jura 05:54, 22 July 2015 (UTC)[reply]
- Delete. I agree with the concern above that the influenced people may not be important to the influencer. For cases where the relationship is important, we already have doctoral student (P185), student (P802), and similar. Deryck Chan (talk) 13:33, 22 July 2015 (UTC)[reply]
- Delete I agree this belongs to the influencee, and it's redundant. author TomT0m / talk page 13:36, 22 July 2015 (UTC)[reply]
- Delete Per Alexander Doria. Casper Tinan (talk) 15:39, 22 July 2015 (UTC)[reply]
- Delete Just used this in Henrik Ibsen and was wondering why I had to use it as it is clearly asymmetrical and unbounded property. I go with Iznos argument, this is a delete. Jeblad (talk) 17:36, 27 July 2015 (UTC)[reply]
- Comment (updating my comment above) this property is used in the frwiki version of Template:Infobox artist (Q5914426) where it matches a prewikidata parameter. It is currently used in 6 pages. --Zolo (talk) 18:05, 27 July 2015 (UTC)[reply]
- Delete Use influenced by (P737) Kharkiv07 (T) 16:30, 8 August 2015 (UTC)[reply]
- Delete confusing. Bruno V.
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 as no consensus (so keep). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:02, 31 July 2015 (UTC)[reply]
Nova Scotia Register of Historic Places ID (P909): (delete | history | links | entity usage | logs | discussion)
The Internet register of historic place of the province aparently disapear last year [2]. The site of the Heritage Property link now only to the Canadian Register of Historic Places[3] (Canadian Register of Historic Places ID (P477))..--Fralambert (talk) 04:39, 27 December 2014 (UTC)[reply]
- Keep that something disappears is not a reason to delete it from Wikidata. E.g. there is Julius Caesar (Q1048). WK7489 (talk) 12:40, 28 December 2014 (UTC)[reply]
- Delete, better to delete disappeared databases because they are not useful but misleading. --Stryn (talk) 12:55, 28 December 2014 (UTC)[reply]
- Comment personally I'd tend to keep it, but it seems only rarely used and its proposer thinks it should be deleted. --- Jura 17:22, 9 January 2015 (UTC)[reply]
- Comment I think it could be deleted but only if we know for sure that t won't reappear. WK7489 misses the point we don't delete what disappeared but the references to it(like you would throw away a note which says "ask Julius Caesar (Q1048)".--Saehrimnir (talk) 06:26, 22 April 2015 (UTC)[reply]
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 --Pasleim (talk) 10:01, 11 August 2015 (UTC)[reply]
architectural style (P149): (delete | history | links | entity usage | logs | discussion)
No tangible benefit from using this property rather than movement (P135). As written in Property talk:P149: The only difference beteween the two properties is that architectural style (P149) is restricted to some classes of items but that does not seem very useful. In practice, p135 is also used for buildings anyway (compare fr:Catégorie:Page utilisant des données de Wikidata/P149 and fr:Catégorie:Page utilisant des données de Wikidata/P135). --Zolo (talk) 11:24, 1 February 2015 (UTC).--Zolo (talk) 11:24, 1 February 2015 (UTC)[reply]
- Delete and merge with movement (P135). Seem the same think, architectural style (P149) only specific to architecture. --Fralambert (talk) 19:54, 1 February 2015 (UTC)[reply]
- Keep "architectual style" (P149). P135 is too vague. --- Jura 12:26, 24 February 2015 (UTC)[reply]
- How is it too vague ? If we say that the movement of monument is neogothic, what can it mean except that architectural style is neogothic ? --Zolo (talk) 16:35, 24 February 2015 (UTC)[reply]
- "movement of a monument is neogothic" require a lot of imagination to make any sense. It maybe works semantically, but it's not an obvious choice for an amateur. -- Innocent bystander (talk) 09:55, 6 March 2015 (UTC)[reply]
- @Innocent bystander: Just add an alias or change the label. TomT0m (talk) 15:24, 6 March 2015 (UTC)[reply]
- Agree, but to what? The problem is that I cannot find any good word that fits one area, but would not be misleading for others and vice versa. -- Innocent bystander (talk) 15:30, 6 March 2015 (UTC)[reply]
- Maybe we could expand P135 for politics as well. "Movement" fits well there ;) --- Jura 20:36, 8 March 2015 (UTC)[reply]
- Agree, but to what? The problem is that I cannot find any good word that fits one area, but would not be misleading for others and vice versa. -- Innocent bystander (talk) 15:30, 6 March 2015 (UTC)[reply]
- @Innocent bystander: Just add an alias or change the label. TomT0m (talk) 15:24, 6 March 2015 (UTC)[reply]
- "movement of a monument is neogothic" require a lot of imagination to make any sense. It maybe works semantically, but it's not an obvious choice for an amateur. -- Innocent bystander (talk) 09:55, 6 March 2015 (UTC)[reply]
- Delete and merge with movement (P135). Per Zolo. --Casper Tinan (talk) 08:17, 6 March 2015 (UTC)[reply]
- Delete TomT0m (talk) 15:24, 6 March 2015 (UTC)[reply]
- Awaiting a bot to clear the current cases. --George (Talk · Contribs · CentralAuth · Log) 17:04, 7 March 2015 (UTC)[reply]
- Keep Unless the English label is changed for movement, it doesn't make sense to merge them as style and movement are not synonymous. (I had to reference a couple dictionaries just to be sure I'm not missing something.) A style can be part of a movement (ie. aestheticism), but not necessarily vice versa. I'm not an expert, but have studied architecture and I've never once heard of a style referred to as a movement. Hazmat2 (talk) 15:56, 27 April 2015 (UTC)[reply]
- It's a stretch to call some architectural styles movements – Modernism yes, Streamline Moderne no – whereas the term "style" always applies to these. But I also see the argument that "architectural style" is to architecture what "movement" is to (e.g.) painting, resulting in the duplication mentioned above. I would prefer to see the properties merged, but called "movement or style"... so Delete. Ham II (talk) 18:59, 12 May 2015 (UTC)[reply]
- Keeptwo different concepts --Rippitippi (talk) 15:04, 13 June 2015 (UTC)[reply]
- Keep. A style is often more specific, 'superficial' and ornamental than an art movement. Comment To slightly contradict - or add nuance to - my opinion: the widely used Art and Architecture Thesaurus by the Getty combines movements and styles in one 'branch' of its thesaurus tree (example). Spinster (talk) 17:11, 24 July 2015 (UTC)[reply]
- Keep, à moins qu'aucun des deux termes ne soit bien choisi. « Style » (qui plus est « style architectural ») et « mouvement » n'ont pas le même sens. Il y a eu un mouvement surréaliste et un style art déco à la même époque mais il s'agit de deux choses différentes. Un mouvement c'est plutôt une organisation formelle ou informelle qui provoque un changement (donc associé plutôt à des personnes) alors qu'un style c'est un ensemble de caractéristiques (plutôt associé à des œuvres). Hier, sans avoir connaissance de la présente discussion, j'ai modifié « La Samaritaine (Q1583780) » où les propriétés « movement (P135) » et « architectural style (P149) » doublonnaient et j'ai jugé que « movement (P135) » n'avait pas de sens pour le bâtiment d'un commerce de grande distribution. Mais mon avis est peut-être hors sujet et je n'exclus pas de n'avoir pas encore compris le concept de propriété de Wikidata. O.Taris (talk) 20:21, 6 August 2015 (UTC) En fait, on a besoin de deux propréités, l'une concernant le style des choses ou œuvres , une autre concernant le mouvement ou le courant artistique, littéraire ou philosophique auquel appartient l'auteur. Le style pouvant éventuellement s'appliquer à une personne en qualifiant son aspect physique (coiffure punk par exemple, sans que son œuvre soit nécessairement punk). O.Taris (talk) 16:28, 9 August 2015 (UTC)[reply]
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 --Pasleim (talk) 10:04, 11 August 2015 (UTC)[reply]
MTR station code (P1377): (delete | history | links | entity usage | logs | discussion)
Redundant to station code (P296). Jc86035 (talk) 13:03, 29 April 2015 (UTC)[reply]
- See discussion for P1655 above. Same for China railway TMIS station code (P1378), --Nenntmichruhigip (talk) 18:10, 30 April 2015 (UTC)[reply]
- Comment At the same time, other people are splitting off specific properties from the more generic; not least so that we can use formatter URL (P1630). We need to agree a project-wide policy on this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:51, 30 April 2015 (UTC)[reply]
- Keep ID sets can overlap, e.g. there are several ID systems to identify countries (three from ISO, Special:WhatLinksHere/Q906278) and many for people. Merging them makes them less accessible. But if you want to do that: Merge all into "identifier" and use qualifier to point to the item describing the ID, e.g. ISO 3166-1 alpha-3 code (Q1341492). FreightXPress (talk) 00:26, 1 May 2015 (UTC)[reply]
- The argument was that we should have one station code (P296) property so all station infoboxes could import info from that property with some lua code to import the "catalog" info from the qualifier. Has that changed now that the various specialised "station code" properties can be marked as "subproperty of (P1647):station code (P296)? Filceolaire (talk) 23:59, 1 May 2015 (UTC)[reply]
- Keep Current quality of station code (P296) values is very low. Adding one more code to this garbage place will make situation worse. — Ivan A. Krestinin (talk) 11:25, 2 May 2015 (UTC)[reply]
- And speedily Keep by formal reason: steps described on this page header were not executed. — Ivan A. Krestinin (talk) 11:32, 2 May 2015 (UTC)[reply]
- Delete Imo it is better to have lesser but more general properties because this makes finding the correct property easier and allows broader usage of few properties. This makes clear that the general idea behind the property is the same. More information can be added using qualifiers or are clear because of the context of the item. For a station code for a station in Hong Kong it is already clear that it is an MTR station code. -- Bene* talk 12:24, 2 May 2015 (UTC)[reply]
- Bene* - one station can have several IDs, like English on Q1860 has a dozen of IDs. Merging into one general language code property would be loss of information. FreightXPress (talk) 23:59, 4 May 2015 (UTC)[reply]
- Wtf? The item you linked is a language, not a station. How can a station have multiple station codes? -- Bene* talk 09:22, 5 May 2015 (UTC)[reply]
- @FreightXPress: Perhaps you are confusing a "station code" with the general identifier datatype. A datatype is not a property. Having only one "station code" property would still allow other properties with the datatype "identifier" to exist. -- Bene* talk 09:24, 5 May 2015 (UTC)[reply]
- Bene* - "How can a station have multiple station codes?" - Can you answer the question how a language can have multiple identifiers? FreightXPress (talk) 17:29, 5 May 2015 (UTC)[reply]
- The "station code" property is about stations, not languages. The discussion about languages is offtopic and does not belong into this RFD. -- Bene* talk 20:07, 5 May 2015 (UTC)[reply]
- The answer for languages could have been an answer for your stations question. It was meant for general education to avoid have this discussion about each class of objects (stations, roads, languages, stars, humans). FreightXPress (talk) 11:45, 7 May 2015 (UTC)[reply]
- The "station code" property is about stations, not languages. The discussion about languages is offtopic and does not belong into this RFD. -- Bene* talk 20:07, 5 May 2015 (UTC)[reply]
- Bene* - "How can a station have multiple station codes?" - Can you answer the question how a language can have multiple identifiers? FreightXPress (talk) 17:29, 5 May 2015 (UTC)[reply]
- Bene* - one station can have several IDs, like English on Q1860 has a dozen of IDs. Merging into one general language code property would be loss of information. FreightXPress (talk) 23:59, 4 May 2015 (UTC)[reply]
- Again, Keep, unless if we can cancel the "Single value" & "Unique value" limits of P296. --Liuxinyu970226 (talk) 03:15, 5 May 2015 (UTC)[reply]
- Keep, ... and also the formal constraints check would have to be dropped, since IMHO there is no universal authority prescribing the format of station codes... Property talk:P296 illustrates the confusion, nobody knows what that property really stands for. If we had an identifier datatype of necessary complexity (at least a triple containing of Q-item for the identifier system, formatter URL and identifier value, currently we model things of such complexity as properties where the "constant" attributes are elegantly dealt with as properties-for-properties), then the deletion request would make sense. For the time being we should abandon station code (P296) (or turn it into a class) to avoid deletion requests for properties one can work with. -- Gymel (talk) 09:52, 5 May 2015 (UTC)[reply]
- @Gymel: Can you provide an example where a station has more than one station code? If I understand that correctly, this property should be used for the official code used for a particular station. Therefore, I think there will be only one official station code per instance. Am I wrong here? -- Bene* talk 12:14, 5 May 2015 (UTC)[reply]
- w:de:Mannheim Hbf: DB: RM, SBB: MAN, IBNR: 8000244, UIC: (unknown, but exists), IFOPT: de:8222:2417:1, Express-3: 8068585. Have I missed any? --Nenntmichruhigip (talk) 12:51, 5 May 2015 (UTC)[reply]
- Ok, I see that point. So either we need a property for each of these databases or use the same property in every place. I don't see which option should be preferred as both ones are not ideal. :-/ -- Bene* talk 20:11, 5 May 2015 (UTC)[reply]
- w:de:Mannheim Hbf: DB: RM, SBB: MAN, IBNR: 8000244, UIC: (unknown, but exists), IFOPT: de:8222:2417:1, Express-3: 8068585. Have I missed any? --Nenntmichruhigip (talk) 12:51, 5 May 2015 (UTC)[reply]
- @Gymel: Can you provide an example where a station has more than one station code? If I understand that correctly, this property should be used for the official code used for a particular station. Therefore, I think there will be only one official station code per instance. Am I wrong here? -- Bene* talk 12:14, 5 May 2015 (UTC)[reply]
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 as keep as no user but the requestor who was blocked as sockpuppet supported.--GZWDer (talk) 16:42, 30 June 2015 (UTC)[reply]
courtesy name (P1782): (delete | history | links | entity usage | logs | discussion)
This property should be monolingualtext. I don't know how to inform the property proposer, since I don't know the username of that user. --FreightXPress (talk) 11:37, 7 May 2015 (UTC)[reply]
- @Zolo: inform the property proposer --Pasleim (talk) 11:51, 7 May 2015 (UTC)[reply]
- Question There is a note about the datatype of this property on its talk page: Property talk:P1782. Has this been resolved? --- Jura 14:44, 7 May 2015 (UTC)[reply]
- Actually, I do not think it can really be resolved, it's just telling that using monolingual text does not appear to work well, as discussed in Wikidata:Property_proposal/Person. What language is 太白 ? Chinese ? But Chinese as we know it did not exist at the time ? So classical Chinese ? That sounds better, but most people, both English or Chinese would pronounce it based on the contemporary Chinese pronunciation. Given that the monoligual property does not provide much benefit beside providing a pronunciation, that is a real issue. And for many people we cannot really tell if this is classical / literary / contemporary Chinese, the person may well have used all those languages, and did not change name in-between, and sometimes Japanese/Vietnamese people use Chinese characters, with may be confusing.
- There are similar issues with other properties as well. Can we really say that the string "Jean-Claude Juncker" is specific to one language ? I would rather turn birth name (P1477) to string than courtesy name (P1782) to monolingual-text
- Note that we sometimes have similar issues with text-related properties like "title", and we chose monolingual text, but for names the issue is more systemic. --Zolo (talk) 14:59, 7 May 2015 (UTC)[reply]
@Zolo, Pasleim, Jura1: If for Chinese it is not accepted with the reasoning that a sequence of characters can be read differently, then Jean-Claude Juncker is a good example - it does not work for any name then. FreightXPress (talk) 23:45, 7 May 2015 (UTC)[reply]
- User was blocked, so I suppose we can close this. Same for the other ones. --- Jura 13:18, 22 June 2015 (UTC)[reply]
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 as keep as no user but the requestor who was blocked as sockpuppet supported.--GZWDer (talk) 16:42, 30 June 2015 (UTC)[reply]
temple name (P1785): (delete | history | links | entity usage | logs | discussion)
This property should be monolingualtext. I don't know how to inform the property proposer, since I don't know the username of that user. --FreightXPress (talk) 11:38, 7 May 2015 (UTC)[reply]
- @Zolo: inform the property proposer --Pasleim (talk) 11:52, 7 May 2015 (UTC)[reply]
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.
eligible voters (P1867): (delete | history | links | entity usage | logs | discussion)
This property duplicate electorate (P1831)
Ping : @Pigsonthewing:, @Милан Јелисавчић:, @Wylve:, @Pikolas:, @Александр Сигачёв:, @Kopiersperre:, @Nikosguard:, @Andreasmperu:, @Nurni:, @GZWDer:, @Pasleim: & @Putnik:. --Dom (talk) 15:13, 20 May 2015 (UTC)[reply]
- Oppose no, it isn't. -- Vlsergey (talk) 15:34, 20 May 2015 (UTC)[reply]
- Please give the difference because there is no huge difference in the descriptions, at least in English. Snipre (talk) 15:53, 20 May 2015 (UTC)[reply]
- Well, shouldn't we start with arguments about similarity first then, before asking for contra? Anyway, P1831 is about place, P1867 is about election. While P1831 is used for statistical reasons, and regularry updated field (updated with year qualificators), P1867 is fixed-value field, with additional restrictions like "single value only". -- Vlsergey (talk) 15:59, 20 May 2015 (UTC)[reply]
- eligible voters (P1867): number of eligible voters for a particular election
- electorate (P1831): number of registered voters for the place
- As I explained but perhaps you didn't read: there is no huge differences in the descriptions. So as you have enough knowledge to say there are not the same, just finish your comment. And no in some countries there is no difference between registered and eligible electors. Snipre (talk) 20:21, 20 May 2015 (UTC)[reply]
- I agree with Snipre, I don't see the difference as the only usage of electorate (P1831) is the election Q16634815. So if if electorate (P1831) must be only linked to a physical location (Q17334923) (or perhaps more precisely to a electoral unit (Q192611)) and not to an public election (Q40231) it must be specified in the specification of this property. --Dom (talk) 08:29, 25 May 2015 (UTC)[reply]
- I don't see the difference between the number of voters in a constituency and the number of voters in an election in that constituency. I think the values above could be indicated with the same property with a point in time qualifier.. Filceolaire (talk) 10:24, 3 June 2015 (UTC)[reply]
- I agree with Snipre, I don't see the difference as the only usage of electorate (P1831) is the election Q16634815. So if if electorate (P1831) must be only linked to a physical location (Q17334923) (or perhaps more precisely to a electoral unit (Q192611)) and not to an public election (Q40231) it must be specified in the specification of this property. --Dom (talk) 08:29, 25 May 2015 (UTC)[reply]
- Well, shouldn't we start with arguments about similarity first then, before asking for contra? Anyway, P1831 is about place, P1867 is about election. While P1831 is used for statistical reasons, and regularry updated field (updated with year qualificators), P1867 is fixed-value field, with additional restrictions like "single value only". -- Vlsergey (talk) 15:59, 20 May 2015 (UTC)[reply]
- Please give the difference because there is no huge difference in the descriptions, at least in English. Snipre (talk) 15:53, 20 May 2015 (UTC)[reply]
- The following scenario should show the difference between the two properties: Election is about to take place at Wikitopia on June 20. Unregistered citizens must register on or before June 1 in order to vote in the upcoming election. On June 2, there are 1000 confirmed registered voters. However this doesn't deter others from registering to become voters. On June 5, 100 more citizens registered to become voters. After that, no more citizens registered. If the government publishes a report on the election on June 20, the eligible voters (P1867) would be 1000 (referring to the election) and the electorate (P1831) would be 1100 (referring to Wikitopia). —Wylve (talk) 18:51, 20 May 2015 (UTC)[reply]
- @Wylve: Which is the number who tells the numbers of potential voters and which is the number of registred voters and which is the number of those who actually voted? And to which election are you reffering here? Is it the municipal board of Wikisburg or the national election of Wikitopia? Where I live, different elections have different rules. In my county 193,777 had the right to vote for the regional parliament and 189,842 had the right to vote in the national parliament. These two elections took place at the same day, and we used the same voting-card for both of these elections, together with the municipal election, which I do not know the numbers of voters in, but it should be the same as the regional election. -- Innocent bystander (talk) 20:24, 20 May 2015 (UTC)[reply]
- @Innocent bystander: To model votes, we currently have eligible voters (P1867), electorate (P1831), ballots cast (P1868), total valid votes (P1697) and votes received (P1111). All of those properties should only be included on items about an election only, except for electorate (P1831), which should be included in the constituency item (or item of a certain administrative area). As to your first few questions, eligible voters (P1867) shows the potential number of voters. As to the number of registered voters, we have electorate (P1831). Not all elections require voter registration, so there might be cases where eligible voters (P1867) is higher than electorate (P1831). ballots cast (P1868) shows the total actual ballots inserted into ballot boxes for a particular election, or in other words, the actual number of voters voted.
- @Wylve: Which is the number who tells the numbers of potential voters and which is the number of registred voters and which is the number of those who actually voted? And to which election are you reffering here? Is it the municipal board of Wikisburg or the national election of Wikitopia? Where I live, different elections have different rules. In my county 193,777 had the right to vote for the regional parliament and 189,842 had the right to vote in the national parliament. These two elections took place at the same day, and we used the same voting-card for both of these elections, together with the municipal election, which I do not know the numbers of voters in, but it should be the same as the regional election. -- Innocent bystander (talk) 20:24, 20 May 2015 (UTC)[reply]
- The problem you've raised concerning the discrepancy between municipal and national elections only lies in votes received (P1111), as it is the only property that is not election-specific, but area-specific. I'm not sure what the consensus is, but I would have the municipal and national elections as two items, since they are fundamentally different in nature (different electorate, different candidates and the different jobs carried out by successful candidates). Each election item would have their own eligible voters (P1867). —Wylve (talk) 23:15, 20 May 2015 (UTC)[reply]
- Thank you! You do not have to register here where I live, it's done automaticly. But the lists of voters can be wrong, so the lists of voters are made public during some weeks. If your name by some reason is missing, you can "register" as voter, but such changes in the lists are rare and I have never seen any such number published.
- In the 2015 election of Båstad Municipality (Q499464) (the 2014 election was disqualified since those who counted the votes made some severe mistakes) We had [4] eligible voters (P1867): 11,874 ballots cast (P1868): 7,552. (Båstad Municipality is not divided in constituencies, but larger municipalities are.) total valid votes (P1697) 7,494. 11 out of 13 registred political parties got votes received (P1111). 4 non-registred political parties got a total amount of 8 votes. The 41 seats in the local parliament was divided between 7 different political parties. [5] -- Innocent bystander (talk) 05:37, 21 May 2015 (UTC)[reply]
- The problem you've raised concerning the discrepancy between municipal and national elections only lies in votes received (P1111), as it is the only property that is not election-specific, but area-specific. I'm not sure what the consensus is, but I would have the municipal and national elections as two items, since they are fundamentally different in nature (different electorate, different candidates and the different jobs carried out by successful candidates). Each election item would have their own eligible voters (P1867). —Wylve (talk) 23:15, 20 May 2015 (UTC)[reply]
- Keep From the discussion, it makes sense to have two properties here, and it's obvious that we need more properties for votes. But I think the labels and description of them could be better. I had to change the Swedish labels here, since they did not fit the description in this discussion. -- Innocent bystander (talk) 04:29, 22 May 2015 (UTC)[reply]
- Delete I agree that we must have more properties for elections (as it can be seen on the WikiProject Politics infoboxes), but these two ones don't seems to be very diffrent. --Dom (talk) 08:29, 25 May 2015 (UTC)[reply]
- Delete. I can't see a need for 'number of voters in a constituency' and 'number of voters in an election in that constituency' to be different properties and I have read the examples above carefully. Filceolaire (talk) 10:24, 3 June 2015 (UTC)[reply]
- Keep. The properties describe two distinct relationships between entities. Here are my reasons for keeping the property:
- Not all elections are constituency-based. Keeping this property would allow non-geographical elections, such as notable board elections of a company or party leadership elections.
- Not all elections require registration of voters. Therefore, electorate (P1831) could not be assigned to any constituency/geographical area item.
- The value of eligible voters (P1867) could not be inferred from that of electorate (P1831), as demonstrated in the example above. —Wylve (talk) 16:42, 12 June 2015 (UTC)[reply]
- Keep. The property descriptions are sufficiently clear: it's eligible voters (P1867) eligible voters per election, versus electorate (P1831) registered voters per geographical area. Deryck Chan (talk) 13:52, 22 July 2015 (UTC)[reply]
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.
- Agreed on deletion, no backlinks. Matěj Suchánek (talk) 09:13, 8 July 2015 (UTC)[reply]
P1361 (P1361): (delete | history | links | entity usage | logs)
It has been split into separate properties (Anime News Network person ID (P1982), Anime News Network company ID (P1983), Anime News Network manga ID (P1984), Anime News Network anime ID (P1985)) and I've updated all the items which were using this property, so now this one is no longer needed. - Nikki (talk) 14:41, 7 July 2015 (UTC)[reply]
- Pinging original proposer @Vlsergey: and property creator @Micru: as per the section above which says the template parameters don't actually do anything. - Nikki (talk) 14:44, 7 July 2015 (UTC)[reply]
- Support totally agree with splitting. -- Vlsergey (talk) 16:38, 7 July 2015 (UTC)[reply]
- Delete I totally agree too, thanks for splitting. Thibaut120094 (talk) 18:08, 7 July 2015 (UTC)[reply]
- Delete I agree with deletion and splitting. --Micru (talk) 21:06, 7 July 2015 (UTC)[reply]
- Delete as redundant. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:51, 8 July 2015 (UTC)[reply]
P2022 (P2022): (delete | history | links | entity usage | logs)
Wrng datatype; sorry Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:35, 9 August 2015 (UTC)[reply]
- Speedy delete. --Izno (talk) 16:26, 9 August 2015 (UTC)[reply]
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 keep. --Fralambert (talk) 18:02, 29 August 2015 (UTC)[reply]
Inventari del Patrimoni Arquitectònic de Catalunya code (P1600): (delete | history | links | entity usage | logs | discussion)
Apepars to duplicate Catalan object of cultural interest ID (P1586) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:48, 8 July 2015 (UTC)[reply]
- Have a look at the property descriptions on the talk pages. --- Jura 08:52, 8 July 2015 (UTC)[reply]
- @Pigsonthewing: Could you withdraw this or add a notice on its talk page that it's listed for deletion? --- Jura 05:59, 1 August 2015 (UTC)[reply]
Keep @Pigsonthewing, Jura1: It isn't exactly the same. The property marked for deletion refers to the Catalan Inventory for Architectonic Heritage and has its own inventory numbers to id buildings with different levels of protection, including (but not only) Cultural Asset of Local Interest (Q11910250). OTOH, Catalan object of cultural interest ID (P1586) is the specific id given to those heritage elements which have the highest level of protection, known as Cultural Asset of National Interest (Q1019352). Hope I've made myself clear, thanks for your consideration! --ESM (talk) 15:31, 1 August 2015 (UTC)[reply]
- @Pigsonthewing, ESM, Jura1: --Fralambert (talk) 12:49, 28 August 2015 (UTC)[reply]
- Keep Inventari del Patrimoni Arquitectònic de Catalunya code (P1600) give accès to [6] for Palau Reial Major (Q1116546), usefull for have protection date. --Fralambert (talk) 12:47, 28 August 2015 (UTC)[reply]
- I had marked this section as resolved as the nominator failed to follow up on it. Apparently he chose to cease participation. IMHO it can be archived. --- Jura 12:55, 29 August 2015 (UTC)[reply]
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.
- Strong consensus to keep. The property should be cleaned of it coat of arms to avoid confusion. --Fralambert (talk) 20:13, 29 August 2015 (UTC)[reply]
seal image (P158): (delete | history | links | entity usage | logs | discussion)
Delete this and re-create it with a new id. The data currently on this property is just too inconsistent (4000 images mainly of coats of arms). For an overview, see Property talk:P158/list (long page, takes time to load). The few useful images can be moved to the new property.----- Jura 06:48, 19 August 2015 (UTC)[reply]
- Question What is exactly the problem with this property ? Bad use of a property is not a reason to delete the property. Snipre (talk) 14:02, 19 August 2015 (UTC)[reply]
- Keep. The mess should not be a reason to delete. What could be, though, would be someone interested in seals starting to create numerous items that describe them and link them to places, people, etc. The usual property for images would then, maybe, become sufficient. For the moment keep. Thierry Caro (talk) 01:47, 20 August 2015 (UTC)[reply]
- Comment people using the property currently don't get what they should (images of seals). If there are users who actually get what they want they shouldn't be using it. For both, a new property with the correct data is better. What is the current error rate? 50% or 90%? --- Jura 02:45, 20 August 2015 (UTC)[reply]
- Keep. The proposal makes no argument as to why it is supposed that this alleged problem would not recur. If a "few useful" examples have indeed been identified, a bot can, subject to community consensus, remove all examples but them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 20 August 2015 (UTC)[reply]
- This is correct, no such argument has been made, but otherwise we wouldn't be editing statements here, wouldn't we? --- Jura 13:35, 20 August 2015 (UTC)[reply]
- Keep and clean up existing usage. Multichill (talk) 20:00, 29 August 2015 (UTC)[reply]
- Comment I added a few constraints to seal image (P158) to check for coat of arms images and moved most of the resulting images to coat of arms image (P94). This reduced the number of images from about 4000 to 2000. Maybe someone wants to go through the remaining 2000. --- Jura 07:31, 13 September 2015 (UTC)[reply]
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 --Pasleim (talk) 17:49, 15 September 2015 (UTC)[reply]
P1964 (P1964): (delete | history | links | entity usage | logs)
I have used it extensively on bios of ultramarathon runners. And I now realize that it is useless if there is no change in datatype or whatever may be needed to fix the differences created by cultures and languages. If you exclude my own use of it, it remained pretty much forgotten by anyone till today. I'd love us to have this here so that Wikipedia articles can be sorted automatically but for the moment it cannot work universally and it seems easier to use other properties to get rid of the DEFAULTSORT keyword in biographies. Thierry Caro (talk) 00:59, 20 August 2015 (UTC)[reply]
- What I mean is that for the moment family name (P734) and given name (P735) are much more used than P1964 (P1964) so it might be better to use those to sort biographical articles till we get a new sorting property that works. Thierry Caro (talk) 01:41, 20 August 2015 (UTC)[reply]
- Delete I was skeptic about this author TomT0m / talk page 12:57, 20 August 2015 (UTC)[reply]
- If we replace this with a property that has 'monolingual text' datatype (so we can specify the sortkey to be used for each language/script combination would that fix the problem? Joe Filceolaire (talk) 23:17, 20 August 2015 (UTC)[reply]
- I guess it would make it acceptable. Innocent bystander stated that this would still be a problem for Swedish-speaking users though. Thierry Caro (talk) 01:20, 21 August 2015 (UTC)[reply]
- It would be better, but not perfect, since sv.Wikisource and sv.Wikipedia do not use the same alphabet. I fully support a change to a monolingual datatype. -- Innocent bystander (talk) 05:55, 21 August 2015 (UTC)[reply]
- I guess it would make it acceptable. Innocent bystander stated that this would still be a problem for Swedish-speaking users though. Thierry Caro (talk) 01:20, 21 August 2015 (UTC)[reply]
- Delete Qualifier on the property would probably make it easier to select the correct sortkey than monolingual string-datatype, but as this is about the only formatted field various wikis have, I'd rather leave it with them for now. --- Jura 05:00, 21 August 2015 (UTC)[reply]
- Delete or change to a monolingual string-datatype Thibaut120094 (talk) 12:03, 21 August 2015 (UTC)[reply]
- Per my extensive comments at the creation discussion, delete. This property had no business ever being created. Sortkey should maybe be a badge of some sort. --Izno (talk) 21:00, 29 August 2015 (UTC)[reply]
- Delete Kharkiv07 (T) 23:49, 13 September 2015 (UTC)[reply]
- Delete The defautsort key is language-dependent. It should be handled the same way as aliases. Casper Tinan (talk) 08:10, 14 September 2015 (UTC)[reply]
- Delete I agree totally with Casper Tinan, as I explained on the Project Chat recently, and before that on the creation discussion. It should be handled with labels, not as a property. --Hsarrazin (talk) 18:47, 14 September 2015 (UTC)[reply]
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.
- Strong consensus to keep. Sjoerd de Bruin (talk) 11:14, 5 November 2015 (UTC)[reply]
floruit (P1317) has now been superseded now that work period (start) (P2031) and work period (end) (P2032) have been created.
In pretty much every case where we we want to specify when the subject was active we want to specify a period, not a single date. Even where a subject is only known for one work we know that it took some time to create that work. I think we should Delete the floruit (P1317) property. 23:12, 20 August 2015 (UTC)
- Comment P1317 can be used with several dates and different references: the earliest date would be the "start", the latest "end". If there is a single date, well that's the only one that is known. Scope is slightly different "alive" <> "work period". Not sure if the new properties are of much use. Seems that the revised proposal for them lacked support @Micru: strange that it was actually created. --- Jura 04:45, 21 August 2015 (UTC)[reply]
- Comment It seemed logic to follow the structure of "start" and "end", while P1317 can be used for "point in time".--Micru (talk) 21:01, 21 August 2015 (UTC)[reply]
- Comment floruit can be both very large and very specific, not sure if it's really superseded now that work period (start) (P2031) and work period (end) (P2032). Floruit is not exactly about activity but about attestation (we now that someone or something existed at some point in time). On Special:WhatLinksHere/Property:P1317, most uses seems to be on a single date. On Aristius Fuscus (Q8824) or Diagoras of Melos (Q353264), sure we can use others properties (like work period (start) (P2031) and work period (end) (P2032) or date of birth (P569) and date of death (P570) - at this point of lack of precision, there is no difference anymore - but it will be a bit ridiculous and overkill) Cdlt, VIGNERON (talk) 09:42, 13 September 2015 (UTC)[reply]
- Q2822101 might be an interesting sample for P1317 and P570. --- Jura 07:50, 7 October 2015 (UTC)[reply]
- Keep Does this proposal mean that when I have only a single floruit date, I should enter it twice in the work period (start) (P2031) and work period (end) (P2032) properties? That seems inelegant, and also leaves open the possibility that some editors will not bother to fill in both dates, resulting in doubt over whether the second date was intended to be equal to the first date or is just unknown. I agree with Jura's comment: an unordered list of floruit (P1317) dates would do the job just as well. --Heron (talk) 20:00, 19 September 2015 (UTC)[reply]
- Keep sometimes a single date or one rough guess is all our sources give us. --HHill (talk) 11:32, 21 October 2015 (UTC)[reply]
- Keep work period (start) (P2031) and work period (end) (P2032) should be used when sources give a specific date range for the period of activity. floruit (P1317) should be used when only specific points in time are known. Both are found widely in the literature, depending on what is known; so it is useful to be able to express either type of statement. Multiple uses of floruit (P1317) are not a satisfactory substitute for work period (start) (P2031) and work period (end) (P2032), because they would not capture the implication that the source identifies this as representative of the whole span of the period of activity. Jheald (talk) 15:27, 21 October 2015 (UTC)[reply]
- Keep per Jheald, but change description so it does not contradict American Heritage Dictionary 3rd edition, which defines floruit as "The period during which a person, school, or movement was most active or flourishing."
- Given (a) that the property is date-valued rather than item-valued; and (b) that the known date of a particular work may not reflect when a person was most flourishing, can I suggest to amend your text to "A date at which a person, school, or movement was active or flourishing." Jheald (talk) 23:04, 27 October 2015 (UTC)[reply]
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 to delete --Pasleim (talk) 12:55, 9 November 2015 (UTC)[reply]
name in native language (P1559): (delete | history | links | entity usage | logs | discussion)
As indicated in the creation discussion of native label (P1705), the property name in native language (P1559) is very specific to person, while native label (P1705) can be used for places, events and people. I suggest to merge them to P1705.--Eran (talk) 07:30, 23 September 2015 (UTC)[reply]
- Note: ruwiki use this property in various templates. I added links to this discussion from their talk pages. Eran (talk) 07:37, 23 September 2015 (UTC)[reply]
- Person name is not "local", in general it is very hard to define what "place" is person belongs to. But it is very simple to define what native person language is. P1559 is not about person name in local language, but in person native language. It may be similar, but it is different by definition. -- Vlsergey (talk) 15:25, 23 September 2015 (UTC)[reply]
- Keep, many strongly defined and accurate named properties are better than single property with several meanings, domain everything and name something1 / something2 / something3. — Ivan A. Krestinin (talk) 21:19, 23 September 2015 (UTC)[reply]
- Keep as Ivan. Joe Filceolaire (talk) 23:27, 6 October 2015 (UTC)[reply]
- Keep per Ivan: very useful to have a specific property only for persons. —MisterSynergy (talk) 06:24, 14 October 2015 (UTC)[reply]
- Delete, but not for the reasons given. This is redundant to the actual label and the native language (P103) property. --Yair rand (talk) 12:07, 14 October 2015 (UTC)[reply]
- People are not necessarily named in their own first language, as people can grow up in a different cultural environment than the one that is used for naming them. In some cases people can get a name in a language they don't even master themselves. so their native tongue (P103) won't be the one for their name (P1559). - cycŋ - (talk • contribs • logs) 12:12, 14 October 2015 (UTC)[reply]
- I am confused. The labels of P1559 and P103 are "name in native language" and "native language" (in English, at least). Are you considering "first language", "native language" and "native tongue" to mean different things? --Yair rand (talk) 12:23, 14 October 2015 (UTC)[reply]
- I understand your confusion, but think about whose native language we are talking about. P103 is the one the person him- or herself has as native language, but P1559 is given before one learns to speak, usually by (one of the) parents. People who are, for instance, adopted and raised raised a different environment, may very well develop another native language than their name-giver has, so the native language for P103 may differ from the one for P1559. - cycŋ - (talk • contribs • logs) 12:38, 14 October 2015 (UTC)[reply]
- Cycn: Good point. Comment 1: what would be a better way to deal with this problem? Passport name instead of native tongue? Comment 2: we can of course set multiple “original names” of different languages to deal with this problem. —MisterSynergy (talk) 12:41, 14 October 2015 (UTC)[reply]
- I think that the original lable was 'Name at birth', but that was a previous property. "Birth name in name-giver's language" or something like that would cover this, I suppose. I don't know if people can have birth names in different languages. This could happen if the parents have different languages and they decide to give their child the same in those two languages. I think this property is for the official name, versions of this name in different languages may be used, but lots of people are called by different names than their official one(s). - cycŋ - (talk • contribs • logs) 12:53, 14 October 2015 (UTC)[reply]
- The idea of this property is not to keep track of name changes due to marriage or similar things. It is more about having an origin for any transcription into other languages, because basically all representations of a name in other languages have the same origin. Therefore, multipe values are a good idea after marriage (to keep old and new “original name”) and in cases of multi-language persons or changed habits of the native language in their home country (example: Russian original name became Ukrainian original name after breakup of the Soviet union. This also has impact on how these names are transcribed into other languages). For that reason, I’d rather avoid the term “birth” in the description. —MisterSynergy (talk) 13:07, 14 October 2015 (UTC)[reply]
- I think that the original lable was 'Name at birth', but that was a previous property. "Birth name in name-giver's language" or something like that would cover this, I suppose. I don't know if people can have birth names in different languages. This could happen if the parents have different languages and they decide to give their child the same in those two languages. I think this property is for the official name, versions of this name in different languages may be used, but lots of people are called by different names than their official one(s). - cycŋ - (talk • contribs • logs) 12:53, 14 October 2015 (UTC)[reply]
- I am confused. The labels of P1559 and P103 are "name in native language" and "native language" (in English, at least). Are you considering "first language", "native language" and "native tongue" to mean different things? --Yair rand (talk) 12:23, 14 October 2015 (UTC)[reply]
- Yair rand: The label depends on user settings and is a transcribed version of the original name of the person. In case of different alphabets (e.g. western, cyrillic, arabic, east-asian, …), the differences of the original name (as kept by this property) and the labels (in other languages) could be quite dramatic [7]. However, since the transcription is always based on some original name, we should have a property to systematically store this original name—this is Property:P1559. (An automatic multi-language transcription tool would be nice, btw.) —MisterSynergy (talk) 12:41, 14 October 2015 (UTC)[reply]
- People are not necessarily named in their own first language, as people can grow up in a different cultural environment than the one that is used for naming them. In some cases people can get a name in a language they don't even master themselves. so their native tongue (P103) won't be the one for their name (P1559). - cycŋ - (talk • contribs • logs) 12:12, 14 October 2015 (UTC)[reply]
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.
P2122 (P2122): (delete | history | links | entity usage | logs)
Wrng data type, sorry Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:07, 28 September 2015 (UTC)[reply]
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 to delete. Sjoerd de Bruin (talk) 11:11, 5 November 2015 (UTC)[reply]
structure replaced by (P167): (delete | history | links | entity usage | logs | discussion)
Redundant to replaced by (P1366) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:37, 8 July 2015 (UTC)[reply]
- Keep There is significant ambiguity in the idea of "replaced by" when dealing with things that are not explicitly part of a series in the way that presidents (etc.) are. I think it is useful to have a property that explicitly states the replacement was spatial. An object could be replaced both spatially and functionally in two different ways. Antrocent (talk) 03:14, 15 July 2015 (UTC)[reply]
- Keep per Antrocent. I have added a statement that this is a 'subproperty of:replaced by'. Eventually we will be able to search on 'replaced by (including subproperties)'. Filceolaire (talk) 03:17, 21 July 2015 (UTC)[reply]
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 to delete --Pasleim (talk) 12:56, 9 November 2015 (UTC)[reply]
official blog URL (P1581): (delete | history | links | entity usage | logs | discussion)
Created with no answer to the concerns I raised. Duplicates official website (P856), which has the alias "official blog". Only used on ten items. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:13, 8 July 2015 (UTC)[reply]
- Delete Redundant, there should be a qualifier for official website that allows the specification of what type of website though. Antrocent (talk) 03:09, 15 July 2015 (UTC)[reply]
- @Antrocent: so, typing via a qualifier? What property would be used for qualifier? "instance of"? The value would be something like blog (Q30849)? Egon Willighagen (talk) 11:52, 13 September 2015 (UTC)[reply]
- Delete agree with Antrocent, here --Hsarrazin (talk) 23:20, 16 July 2015 (UTC)[reply]
- Keep I don't see what the benefit to changing it to a qualifier would be, nor is it clear to me which qualifier is even being proposed. I would rather remove the blog aliases from official website (P856) (the first of which, as far as I can tell, was added by you after this property had been created) and add subproperty of (P1647) official website (P856) to this one. As for it only being used 10 times, it sounds like we actually need to add/import more data (en:Template:Official blog would be a start). Also pinging @DunDunDunt, AmaryllisGardener, Ivan A. Krestinin, Micru: who proposed/supported this property originally. - Nikki (talk) 03:07, 17 July 2015 (UTC)[reply]
- Keep per Nikki. Filceolaire (talk) 03:14, 21 July 2015 (UTC)[reply]
- Keep per Nikki. Most entities for which this could be applied have a unique official (main) website and unique official blog. This property would be quite useful to import data from Wikipedia. Innotata (talk) 02:45, 29 July 2015 (UTC)[reply]
- Comment Not sure but rather Delete. How can you tell what is a website and what is a blog? I don't see examples where this little difference matters. Constraints on official website (P856) should be adapt (no more unique and adding an ad hoc qualifier). @Innotata : can you provide an example? Cdlt, VIGNERON (talk) 07:47, 30 July 2015 (UTC)[reply]
- Official website normally should point to a general homepage of an organization or person, while official blog points to a site where periodical posts are made. Taking some examples from the English Wikipedia templates, www.microsoft.com vs. blogs.microsoft.com for Microsoft (Q2283); www.koizumix.com vs. ameblo.jp/koizumixproduction for Kyōko Koizumi (Q1197212). Innotata (talk) 00:22, 2 August 2015 (UTC)[reply]
- Keep per Innotata. Sorry it took me so long to vote, I must not have paid attention to my ping notification. --AmaryllisGardener talk 04:26, 29 October 2015 (UTC)[reply]
- Keep per Innotata. Popcorndude (talk) 03:31, 9 November 2015 (UTC)[reply]
Euouae (Q21684732): medieval music mnemonic: (delete | history | links | entity usage | logs)
I've created wrong data. I wanted to link to other languages from "euouae" in the WIkipedia Japanese version, but I did not know how well.--Tail furry () 15:35, 8 December 2015 (UTC)
- No worries. I merged it with Q873550 and redirected it there. --- Jura 16:05, 8 December 2015 (UTC)[reply]
- Thank you for your actions.--Tail furry () 16:23, 8 December 2015 (UTC)
Property:P659, Property:P857 and Property:P1152
edit
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 keep --Pasleim (talk) 09:20, 30 November 2015 (UTC)[reply]
Please delete the above until there is a consensus on on how to define it.
There seems to have been a misunderstanding at Wikidata:Property_proposal/Place#Commonwealth_War_Graves_Commission_burial_ground_identifier on how to define it.
The property was created too quickly by the proposer. --- Jura 21:30, 30 May 2015 (UTC)[reply]
- Keep This is overkill. Jura agreed that the property should be created. I misread his comment about one detail, and now we have a disagreement about how it should be used, which can be resolved - as I requested them to do; see their talk page - in a talk page discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:57, 30 May 2015 (UTC)[reply]
- I don't think the datatype is a minor detail. To avoid disrupting our downstream users, let's delete this until the proposal discussion comes to a conclusion. Otherwise we end up with more unresolved problems as with the ones you created for Wikidata:Project_chat/Archive/2015/05#How_to_record_property_examples, this despite people providing feedback. --- Jura 04:03, 31 May 2015 (UTC)[reply]
- The data type will be "string", whether we record the full identifier or just the numeric part. The linked, archived, discussion to which you link is immaterial to this matter. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:48, 31 May 2015 (UTC)[reply]
- It's no big deal to delete this. I'm sure we will be able to sort it out eventually. --- Jura 06:33, 1 June 2015 (UTC)[reply]
- It's no big deal to keep this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:34, 1 June 2015 (UTC)[reply]
- It's no big deal to delete this. I'm sure we will be able to sort it out eventually. --- Jura 06:33, 1 June 2015 (UTC)[reply]
- The data type will be "string", whether we record the full identifier or just the numeric part. The linked, archived, discussion to which you link is immaterial to this matter. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:48, 31 May 2015 (UTC)[reply]
- I don't think the datatype is a minor detail. To avoid disrupting our downstream users, let's delete this until the proposal discussion comes to a conclusion. Otherwise we end up with more unresolved problems as with the ones you created for Wikidata:Project_chat/Archive/2015/05#How_to_record_property_examples, this despite people providing feedback. --- Jura 04:03, 31 May 2015 (UTC)[reply]
- Keep It's not an ideal situation, but the property exists now and I don't see what deleting it would achieve. It's not clear that the property is wrong as it is. The property does seem to be wanted in some form. Deleting it does not help us store the data. Deleting it does not help to define how it should be used. Deleting and later recreating it (potentially unnecessarily) does not prevent disruption to downstream data users. In fact, I would say the best way to avoid disruption to downstream users would be to focus on determining the best way to store the data so that any changes that are needed can be made as soon as possible, not to get sidetracked by trying to delete it before it's clear that deleting it is even necessary. - Nikki (talk) 10:36, 1 June 2015 (UTC)[reply]
- It's a data type and content format issue. I guess we could just create properties and then discuss them. That could be a new approach, apparently already practiced at Wikidata:Properties_for_deletion#Property:P1904. --- Jura 10:56, 1 June 2015 (UTC)[reply]
- Now you're just making things up. Why? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:58, 1 June 2015 (UTC)[reply]
- It's a data type and content format issue. I guess we could just create properties and then discuss them. That could be a new approach, apparently already practiced at Wikidata:Properties_for_deletion#Property:P1904. --- Jura 10:56, 1 June 2015 (UTC)[reply]
- Calm down the pair of you. Andy Mabbett you shouldn't be creating properties you proposed yourself. Please don't do that again. Jura this is an issue which could have been handled better and with less drama by some direct communication on another forum. Filceolaire (talk) 10:48, 3 June 2015 (UTC)[reply]
- I am, and have been throughout, perfectly calm. When I asked whether I should create properties I proposed myself, on the "Project chat" page there were zero objections. Indeed, one editor thanked me for doing so: Jura. However, I already refrain from doing so where there are objections. As I have already stated on Jura's talk page, with an apology, I misread Jura's latter comment on the proposal in this case. As you can see there, I also invited Jura to raise his concerns on talk page. He has not done so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:41, 3 June 2015 (UTC)[reply]
- Here is the explanation given to Andy: User_talk:Pigsonthewing&oldid=220781386. --- Jura 16:12, 10 June 2015 (UTC)[reply]
- And here is the rest of the conversation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:53, 10 June 2015 (UTC)[reply]
- So, are you going to do the right thing? --- Jura 09:55, 18 June 2015 (UTC)[reply]
- Jura there is no consensus to delete this property so it would be improper for Andy to do that. The creation discussion is archived at Wikidata:Property_proposal/Archive/31#Commonwealth_War_Graves_Commission_person_identifier. You have links to various other conversations none of which, are clear (to me) as to what the problem is. The discussion above indicates there is some problem as to how much of the url should be used as the identifier. If this is the problem then it doesn't justify deletion. It's a practical implementation detail which (in my opinion) should be discussed on the property talk page (not in user talk pages - it's important later users of this property can see the discussion). Keep. Filceolaire (talk) 22:09, 16 July 2015 (UTC)[reply]
- So, are you going to do the right thing? --- Jura 09:55, 18 June 2015 (UTC)[reply]
- And here is the rest of the conversation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:53, 10 June 2015 (UTC)[reply]
- Here is the explanation given to Andy: User_talk:Pigsonthewing&oldid=220781386. --- Jura 16:12, 10 June 2015 (UTC)[reply]
- I am, and have been throughout, perfectly calm. When I asked whether I should create properties I proposed myself, on the "Project chat" page there were zero objections. Indeed, one editor thanked me for doing so: Jura. However, I already refrain from doing so where there are objections. As I have already stated on Jura's talk page, with an apology, I misread Jura's latter comment on the proposal in this case. As you can see there, I also invited Jura to raise his concerns on talk page. He has not done so. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:41, 3 June 2015 (UTC)[reply]
- The property is still ill defined => Delete (wrong datatype or definition) --- Jura 04:38, 8 August 2015 (UTC)[reply]
- As you're the person who opened this section (which was already long-overdue for closure), this constitutes a second "!vote". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:36, 14 August 2015 (UTC)[reply]
- What is a "!vote"? Not sure if you can even count. Anyways, even simple cases here take forever .. Wikidata:Properties_for_deletion#Property:P1600 etc. --- Jura 05:42, 15 August 2015 (UTC)[reply]
- As you're the person who opened this section (which was already long-overdue for closure), this constitutes a second "!vote". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:36, 14 August 2015 (UTC)[reply]
- Keep If the CWGC actually have identifiers and they use them. Delete if they do not. If there is disagreement over an aspect, fix that aspect and seek assistance of some party to mediate, not haggle over a deletion based on prematurity of creation. Noting that six months later it has 6 uses. — billinghurst sDrewth 04:26, 10 November 2015 (UTC)[reply]
- It probably only has six uses because it's had a deletion "sword of Damolcles" hanging over it for six months. Nonetheless, those six cases prove that the CWGC both have identifiers and use them, so your condition for keeping is met. Please can this now be closed? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:57, 25 November 2015 (UTC)[reply]