Latest comment: 9 years ago19 comments10 people in discussion
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.
Originally this property was supposed to mean that an item is under jurisdiction of an entity. Over time it took up other roles like an item applies to a certain jurisdiction and that an item contains certain jurisdictions. Currently it is a mess, so I propose to deprecate this property and create 3 more specific properties:
@Closeapple: So far I haven't seen any use of p131 other than to denote government-related entities. If other uses were acceptable, then I still think it is necessary to reboot p1001. It has too many inconsistent uses and the labels in other languages refer to different concepts.--Micru (talk) 11:08, 7 July 2014 (UTC)
@Closeapple: alternatively all labels and descriptions from p1001 could be deleted so the users can translate the current label into other languages, with the hope that the wrong uses of this properties will be corrected over time.--Micru (talk) 08:06, 9 July 2014 (UTC)
@Filceolaire: I think you are opposing the original deletion proposal, but that has changed (see below). The current proposal is to deprecate p1001 in favour of a generic "applies to" property (based on p:p518). Of course while p1001 is deprecated there would be time to move the statements either to "is in administrative territorial entity" or to "applies to".--Micru (talk) 08:32, 10 July 2014 (UTC)
Oppose. (Abstain on whether to keep or delete.) This property is problematic, but replacing it with a generic "applies to" leaves the meaning ambiguous, and might not work well in all languages. --Yair rand (talk) 20:51, 11 September 2014 (UTC)
Oppose. It could be renamed, but it's an important enough statistic that we should keep it. Also, Yair_rand is probably right that merging it with P:applies_to would create ambiguity in a number of languages. P:applies_to is a qualifier that means "this property is only valid in these contexts" whereas P:jurisdiction means "this item only has authority over that item". P:jurisdiction also isn't the same as P:in_administrative_entity; for example, High Court of Justice (Q1617747) is in England but it has jurisdiction over England and Wales while Senedd (Q493517) is in Wales and only has jurisdiction over Wales. The jurisdiction property could possibly also have non-geography values; for example, a medical ethics review board only has jurisdiction over registered doctors and nurses. --Arctic.gnome (talk) 19:21, 12 September 2014 (UTC)
Latest comment: 9 years ago10 comments5 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The functionality of this property can be covered by the (already existing) has part(s) (P527). For many Belgium and Dutch municipalities I used has part(s) (P527) in the past to do the same as P1383 aims to do (list all villages within a municipality). So in my opinion this property was not needed. Michiel1972 (talk) 11:35, 15 August 2014 (UTC)
They are not parts. They don't form a municipality. The municipality is not a collection of settlements. The municipality is an administrative entity, settlements are geographical entities. The municipality administers the settlements. The settlements belong to the jurisdiction of the municipality. They are not parts. P150 is just good, if we lift the restriction. Otherwise P1383 should be used. I don't understand why P150 is restricted. It is the same relation. --JulesWinnfield-hu (talk) 19:58, 17 August 2014 (UTC)
contains settlement (P1383) just like contains the administrative territorial entity (P150) is a property in many infoboxes. The only reason P150 can't be used is a constraint that restricts it only to administrative entities and excludes settlements that are not administrative entities. It just cuts off the last level in a hierarchy. The settlements of an administrative unit is an exact, legal fact, not among other whatevers. What property do you suggest to list them? --JulesWinnfield-hu (talk) 10:22, 3 November 2014 (UTC)
Ok, for now this property may be kept (withdraw PfD). It's more appropriate using P527 for villages. In the future P1383 maybe merged with P150 when its definition is changed. Michiel1972 (talk) 09:16, 19 January 2015 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
@Dereckson: the proposal was to change the datatype, not to merge the properties.
I think this should indeed be better, but, for inscriptions at least, I would rather wait until we know if we can add "no language" and "language undetermined" (see bugzilla:70205).--Zolo (talk) 10:57, 1 September 2014 (UTC)
Sounds reasonable, but we can probably create monolingual-text versions of these in the meantime, even if we can't delete the old ones yet. --Yair rand (talk) 21:43, 3 September 2014 (UTC)
Yes it may take some time to make the full conversion anyway, as we need to add the language value that for each statement, and many are probably not provided as qualfiers. Also, we should probably let the old properties coexist with the new for some time, so that clients can adapt their codes. --Zolo (talk) 13:13, 4 September 2014 (UTC)
Oppose against the change. We already have original language of film or TV show (P364) and language of work or name (P407) to mark item language, enforcing language specification into every title is overcomplication. (existing of new property is not an argument -- to create new property we needed 3 people, not consensus). Also, there is still no answer what to do with artificial languages that can't be specified in drop-down list (but have appropriate q-IDs). Or what to do with titles like "cthulhu fhtagn" (no, that is not English). -- Vlsergey (talk) 10:32, 19 September 2014 (UTC)
@Vlsergey: You assume that title and subtitle are always in the same language than the text but this is not always the case. If you think about translations you have titles which are not translated (TV series or movies can keep the title in the original language even if the version is in another language). I find more disturbing the use of original language and language in the same item than having to enter several times the language. It is better to lose a little more time at the beginning to enter clear data than to spend more time in the future to understand the different ways to use original language and language by several thousands of contributors. The only reason to keep P357 (P357) is if we don't have the possibility to select the proper language.
@Snipre: 1. no, i do not and never assumed that. But I assume (try to prove me wrong) that 99% of cases title and subtitle are in the same language. 2. Handling translations is different questions. I can hardly understand why you trying to keep data "clean" using new datatype and at the same time keeping data "dirty" by placing different subjects (original movie and translations) into the same entity. 3. One can always change it back, it is not an argument. 4. You must not start any operation until we have consensus, sorry. -- Vlsergey (talk) 13:32, 30 September 2014 (UTC)
@Vlsergey: The consensus for moving P357 (P357) to title (P1476) exists from more than one year and was approved with the guideline for sourcing (see here). If we start to discuss again and again topics which were solved, we never take decisions. Title was ever one of the main reasons of the development of the monolingual datatype. According to the comment on Help:Sources this was planned and announced to everyone using that guideline. So if you want a consensus to delete P357 (P357), I agree and I think we have to solve exceptions before to do that, but there is no need of consensus to move P357 (P357) to title (P1476) because the consensus exists already.
You don't assume that 100% of the titles have the same language than the text but you assume only 99%. If you start to ask me to prove anything I can play childish and ask you to do the same. Here the question is not to know who has the longest d..k but to think and to propose solutions which can be applied to the maximum of cases in order to avoid exceptions which are a nightmare to solve and to be sure that all contributors will apply.
"Handling translations is different questions." No this is not a different question: again we need global solutions, for original work and their translations. Do you want to start a help page describing all different scenarios and how to solve them ? With the monolingual datatype we get ride of the difference original language and language and we don't have to start to work with qualifiers. Snipre (talk) 15:07, 30 September 2014 (UTC)
Another thing that may be worth noticing is that most Wikipedias seem to recommend putting foreign language string inside a Template:Lang (Q6610935). Now I am not sure it is tremendously useful, but it is so widely done that I suppose there are valid reasons for it. And this can be done much more simply, and more accurately, with monoligual text than with normal strings. -Zolo (talk) 14:28, 30 September 2014 (UTC)
The original language of the film Fack ju Göhte (Q15268063) is German. But what language is the title: Fack ju Göhte? German or wrong spelled English? And if the title is a name like "Anna"? The film might be French, the person whom the name belongs to English but the author has choose it because he thought of his Spanish girlfriend. --Kolja21 (talk) 16:03, 30 September 2014 (UTC)
There will be cases that are hard/impossible to determine. This is the reason behind bugzilla:70205. For titles like "Anna", I tend to think this should be considered to be in the same language as the original language of the movie, unless we have reasons to consider otherwise. --Zolo (talk) 07:41, 1 October 2014 (UTC)
@Kolja21. Very bad examples. Fack ju Göhte: Can't be wrong spelled English because English doesn't use "¨". "Anna": Can the string datatype solve that problem ? No, both string and monolingual datatypes fail to solve that problem. But you can apply the same reasoning to solve both cases: the language of the title is the same like the language of the original text/movie. Snipre (talk) 16:12, 1 October 2014 (UTC)
Support, agree with Yair rand. The "no language", "language undetermined" and "uncoded language" possibilities should be added to the datatype, though.--Shlomo (talk) 11:19, 14 October 2014 (UTC)
Comment Can we just change these properties' data type from string to monolingual text? Is it technically possible? If so, we do not need to delete these properties. --Neo-Jay (talk) 04:10, 29 October 2014 (UTC)
Comment As far as I understand, the main problem of switching from string to monolingual text is that we cannot omit the language when entering monolingual text. Thus, we will not be able to enter some special cases of titles, so we will either need two separate properties (which is not good) or to add special cases for the language part like "language undefined" or "no language". But if we have monolingual text with "no language", do we really need string data type at all?:) --DixonD (talk) 19:55, 23 November 2014 (UTC)
Latest comment: 9 years ago21 comments10 people in discussion
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.
Since property 'event location' P766 has been merged last week with location (P276), and its definition is getting to a more generic 'location' property, I think P1134 can now also be merged into P276. So the new definition of P276 wil then change from: location the object or event is within to location the object, event or item is within. Michiel1972 (talk) 09:55, 13 December 2014 (UTC)
"Is not about a object or a event, but about place within a park" - P276 is about the location, not an event. It can also accept a place within a park as value.
"but about place within a park, a historic district or a another non administrative unit" - A park and a historic district are also administrative entities.
I see P1134 as usefull to link a place to a statistical or a non administrative divisions. I see more P1134 as a place in a zone and P276 as a point location. I am not sure I want to see the buildings and the event of a village like Gentilly (Q5533651) in the same property.
It has already been decided to use P276 on events and on physical objects. Selecting geographical features of a park? Select everything that is located in the park and is a geographical feature. I think : "claim[276:(tree[<your location choice>][][276])] and claim[31:(tree[<your class choice>][][279])]" where location choice can be Yellowstone National Park (Q351) and class choice can be one of the classes that are subclasses of geographical feature (Q618123)[1]. Or you take the top class and remove some, e.g. remove human-geographic territorial entity (Q15642541) by adding " and noclaim[31:(tree[15642541][][279])]". Does this help? Frank Robertson (talk) 01:56, 14 December 2014 (UTC)
The first item that has P1435 that I looked at is Eiffel Tower (Q243). It has "located in the administrative territorial entity (P131)" : 7th arrondissement of Paris, Paris, Île-de-France. No physical location. Also the 7th is in Paris and Paris is in Ile-de-France, so the latter two could be redundant. One reason to not delete P131 could be, that it is nothing physical. The 7th arrondissement has no mass. Crimea is an example, where different administrative entities exist in the same area - laws of physics say this is impossible. These simply are no physical objects. Frank Robertson (talk) 02:37, 14 December 2014 (UTC)
So can country (P17), but is it a usable data-model where most properties has to be obtained through two, three or four levels of inheritance? As long as there is no implicit inheritance-statements in Wikidata, I'd say no, it is not. /ℇsquilo07:03, 15 December 2014 (UTC)
Comment ... but I can see editors choosing <painting> 'location:Dutch masters gallery' which is 'part of:national gallery' (and allows a transitive relationship between a museum and its galleries). So a pure location walk up the tree wouldn't work - queries would need to consider both location and part relationships. - PKM (talk) 20:00, 23 December 2014 (UTC)
Comment I'm not sure is a fusion-deletion is the best option. Shouldn't we think about re-organizing these properties ? For me located in the administrative territorial entity (P131) is not just about location but far more precise : the location is not just any place but an administrative territorial entity, and the item is not just in this entity but belongs to this entity (with implications for the laws for instance). Idem for located in/on physical feature (P706), it's not just a location it's about ecosystem and natural stuff too. When the location is not administrative nor « geo-physical-natural-whatever » (it could be statistical, sociologic, historical, traditionnal, fictionnal, etc.), P1134 (P1134) seems the right property to me. In the same spirit, on the french Wikipédia, we have several articles for similar thing. Eg. Aix Island (Q2061380) and Île-d'Aix (Q214568) (I took a simple one), what properties should be use to describe the relation beetween this two items ? An other correlated point : how should we use these properties ? Eg. Property_talk:P131#How_many_layers_to_include.3F wich has not really been cleared. Cdlt, VIGNERON (talk) 20:58, 4 January 2015 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Latest comment: 9 years ago7 comments7 people in discussion
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.
Latest comment: 9 years ago4 comments4 people in discussion
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.
Latest comment: 9 years ago25 comments18 people in discussion
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.
Just convert those to P1636. The preference is to use specific properties rather than one property with thousands of qualifiers. --- Jura08:53, 14 December 2014 (UTC)
" 'More direct' time (and location) properties means a special time (and location) property for every type of event. Hundreds of them. With users having to try and find the right one. This is not better."
User:Zolo and User:Tobias1984 supported the creation. Then suddenly a dedicated property P1636 is created, but this does not allow to store the location. One would need an extra one for this. And then, maybe one wants baptizer. So, one has three new properties. And the information related to one event is spread between several properties. Frank Robertson (talk) 21:30, 14 December 2014 (UTC)
@Ayack: Ayack, you created the property. Do you know where the proposal is? - About this deletion request: The two end-members of this discussion are either "one property for all events with qualifiers being used to further describe the events" and "specific properties for any possible event with qualifiers only used for clarifications". In any case I don't think we should take the appearance in the Wikidata-interface into consideration. Wikidata is somewhat of a hybrid between a data-entry form and a data-view. The data is going to be "unübersichtlich" (is unoverviewability a English word?) in either case and special database-view might need to be developed for domain-specific knowledge. (The secret behind "big data" is probably filtering 99.99 % of the information you don't want to see).
To sum this up: We should probably have an RfC about this soon. The question is, if we should enforce one end-member solution or decide for each new property. I personally have started to lean more towards creating more properties. It will be unoverviewable in any case. We need good filtering to solve this. --Tobias1984 (talk) 22:27, 14 December 2014 (UTC)
1)There is no filtering. The UI is as it is. Apart from UI problems: there can be several weddings and divorces, then one has to connect time/location/partner properties for each - how is this done? At Agnes Bulmer (Q16147344) I wanted to add the baptizer, but I found no generic "event/action carried out by". Now, it there is time of baptism and in future location of baptism, then one also needs baptizer. It doesn't scale. Frank Robertson (talk) 22:49, 14 December 2014 (UTC)
@Frank Robertson: Actually it does scale. We already have more than 1600 properties so 16000 is just one order of magnitude more. Increasing this number should not influence our decision, in my opinion. - In any case it might be a good idea to do a thorough review of all the event properties. Do you have time to set up an RfC about this? --Tobias1984 (talk) 07:26, 15 December 2014 (UTC)
@Tobias1984: 1329 at Wikidata:Database reports/List of properties/all, and six of these marked for deletion. Almost 600 of these are of type=string, AFAICS not much else than identifiers. That is ~700 left. From these, only some come as pairs or groups, like the "time of"/"location of" pairs. Where is "location of baptism"? The implementers of "time of baptism" broke storing the location in an obvious property. 91.9.120.7018:30, 16 December 2014 (UTC)
Once we have property-type statements enabled, we will be able to set up subproperty-trees, so that will scale better than it currently does. But still maintaining this tree will add some work.
Beside, as Filceoalaire noted, in addition to the "date of X" tree, we will need a "place of X" tree, and possibly others.
Putting "date of X" and "place of X" in separate statements makes more sense when they come from different source, but still that is a bit unwieldy to work with.
Another benefit of significant event (P793) is that we can have a start date + an end date qualifier. (Admittedly that's off topic in a discussion about baptism, and hopefully, we will be able to do the same thing in the future in a single snak)
1) Regarding location tree: Keep in mind that location itself comes in different forms: "located in the administrative territorial entity (P131)", "located on terrain feature (P706)", "located in place (P1134)" and "location (P276)". So maybe some people then will like to have "baptism located in the administrative territorial entity", "baptism located on terrain feature", "baptism located in place". From physics, I think, time and location is sufficient.
Delete. If someone is baptised twice then using this property as a first rank property won't tell us which date applies to which baptism. Using 'point in time' as a qualifier we do not have this problem. Getting baptised twice may be unusual but getting married twice is not. A politician is often elected to various positions over their career. Each of these positions use the position held (P39) property with qualifiers for start date, end date, preceded by, succeeded by, electoral district. Creating special properties won't help here as these qualifiers each apply to a particular statement. The only way round this is for us to have a separate Qitem for each of these events (rather than including them in the Qitem for the person). This will not (in my opinion) be an improvement. Qualifiers are useful and we should take advantage of them. Filceolaire (talk) 23:46, 17 December 2014 (UTC)
Keep IIRC the intention to introduce a date of baptism property was to be able to record an analogy for date of birth (P569) in cases like Ludwig van Beethoven (Q255) where the date of birth is not known however it is an established fact that in that time baptism a) was already recorded and b) took place within a couple of days after birth. Thus the baptism property was not intended to record another "significant event" (taking up some denomination) in live but rather as an insignificant deviation from but usually quite good approximation to the unknown date of birth (and therefore denomination and place / church of baptism are not relevant in this respect). Of course, when place of birth (P19) and date of birth (P569) will be contracted to some complex "significant-event"-property, the baptism property/ies could change alike. -- Gymel (talk) 00:17, 18 December 2014 (UTC)
CommentBaptism can occur at any time after birth and there can be several occurrences - or none. While for humans there is a 1:1 relation with respect to birth. The property is not labeled
"date of baptism with the intention to be able to record an analogy" or
"date of baptism in cases like Ludwig van Beethoven"
"date of baptism in the Xth to Yth century"
but is labeled "date of baptism". And what is complex about the "significant-event"-property is probably a secret of User:Gymel. Does Gymel find it less complex splitting properties of one event between different statements in a way that doesn't allow the data consumer to know which belong together? Complexity reduced that much, that functionality was lost.... 91.9.121.13101:37, 21 December 2014 (UTC)
Comment One problem with giving dates as qualifiers is that you can't then specify qualifiers on those dates (because you can't have a qualifier on a qualifier). So, for example, you can't mark a date of such an event as "circa" using sourcing circumstances (P1480)circa (Q5727902), or other similar such qualifiers. Jheald (talk) 22:50, 27 December 2014 (UTC)
Keep necessary for many cases, where there is no birth date only date of baptism. The birth date of Martin Luther (Q9554) is not exactly known, but we do know the date of baptism for sure. Usualy it is assumed he was born only a few days before, so the latest possible day is one day before and that day went into the biographies. I think it suits not to use a location (like a church) as a qualifier for a date. A simple property is better to handle in infoboxes than a property with qualifier.--Giftzwerg 88 (talk) 19:43, 11 January 2015 (UTC)
Latest comment: 9 years ago4 comments4 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Please refer to property proposal (btw why can't I find it anywhere in archives?). I believe that according to the discussion the datatype should be Multilingual text instead of Monolingual text..--DixonD (talk) 19:51, 11 December 2014 (UTC)
I suggest add message "Warning: This property will be deleted then multilingual datatype appears. Be ready to switch your algorithms to new property." to the property talk page and keep the property for now. Conversion multiple monolingual values to one multilingual is looked simple. — Ivan A. Krestinin (talk) 20:48, 11 December 2014 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Latest comment: 9 years ago11 comments6 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.A summary of the conclusions reached follows.
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.
(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.
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. --- Jura11:36, 26 February 2015 (UTC)
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)
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)
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)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Latest comment: 9 years ago22 comments10 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Keep No, it is definitely not a duplicate located on street (P669). For starters, P969 (P969) is a string and located on street (P669) is an item. That is the difference, and it can be a big difference because data strings do not dynamically change as data items do. Streets and buildings can change their names over time, addresses can cease to exist. P969 (P969) as a string allows us to explicitly state a precise address for an item at a given point in time, as sourced from formal and official sources, e.g. Companies House in England, for companies registered in England and Wales, company listings on stock exchange websites, etc. Danrok (talk) 16:56, 24 January 2015 (UTC)
Can't qualifiers be used to « explicitly state a precise address for an item at a given point in time, as sourced from formal and official sources » ? Cdlt, VIGNERON (talk) 18:13, 24 January 2015 (UTC)
Item seems the logical type for an adress to me. We won’t « have items for each street in a city even lesser in all places » but we will have items for each street needed in other items. Cdlt, VIGNERON (talk) 18:13, 24 January 2015 (UTC)
This property seems to be useful when no item is available. For the ordinary user, it is much more convenient to copy-paste a string than to create an item, and add a statement with the required qualifiers. However, I do not really know if we should recommend not use this property when an equivalent located on street (P669) is available. It would seem to make sense, but Danrok's argument seems reasonable. --Zolo (talk) 17:52, 24 January 2015 (UTC)
True, P969 (P969) is more simple for user but it's seems to me ambiguous and unusable properly (adresses are not strictly monolingual). Why shouldn’t we the more precise and clear property ? It seems a good recommendation to me. Cdlt, VIGNERON (talk) 18:13, 24 January 2015 (UTC)
Two different ways to do the same thing is not the best solution for sure. If we keep the data structure this way and use street as qualifier to adress, we need at least much more explanations on the properties description boxes and also some more examples how to use it.--Giftzwerg 88 (talk) 18:39, 24 January 2015 (UTC)
Danrok's point was that sometimes we need a precise street as an address, we do not need to just get the meaning right. I am not sure how important this is however. If this is just for very technical legal information, people should probably not turn to Wikipedia/Wikidata for that anyway.
Another isue is no case where a string property does not sound too convenient: is non latin script. Take China: addresses are often provided both in Chinese and in English (but not in other languages). Though the Chinese -> English tranformation usually follows a regular pattern, it more complex to retrieve programmatically than a mere transliteration (四川北路44号 -> "44 Sichuan Rd (N)." not "sichuan beilu 44 hao"). Given that an address in English (+ Arabic, Russian etc?) seems necessary for many people to understand, that requires at least two statements). By the way, it suggests that the datatype is more monolingual text than string.
I tend to think the ideal solution would be: let users type string and have (smart) bots that can turn them into items when they can make sure that it matches. --Zolo (talk) 09:10, 25 January 2015 (UTC)
Keeplocated on street (P669) and P969 (P969) have different usages and different datatypes. The located on street (P669) label of the item pointed to by this property can be translated and transcribed into any language. P969 (P969) on the other hand is the complete address in the local language and charachter set (i.e. what you have to write on the envelope of a letter if you want it to be delivered to the right place). For example, "Свеавеген" is a perfectly acceptable name in russian for the street Sveavägen (Q1788276), but the address is still "Sveavägen". This actually made more sense before someone changed the labels. /ℇsquilo14:34, 27 January 2015 (UTC)
Keep As the discussion shows, it is not possible to merge properties with different valuetypes string and item. The questioned property can not be replaced easily. This property is not completely stuctured, so it can contain more than located on street (P669). Even if we have hypothetically an item for every street that is described as a value for {(P|969)}, we can not cover every possible usage of P969 like the russian additional informations in the adresses, there are also some cases, where there is no street contained in the adress. --Giftzwerg 88 (talk) 15:48, 3 February 2015 (UTC)
Latest comment: 9 years ago13 comments11 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Not useless, e. g., United Kingdom is shortened UK language-independant, but a monolingual datatype would be more useful; Support --Akim Dubrow (talk) 17:55, 6 September 2014 (UTC)
United Kingdom of Great Britain and Northern Ireland is shortened to United Kingdom or Royaume Uni etc. Looks like multilingual datatype is required. Filceolaire (talk) 15:10, 19 December 2014 (UTC)
I'm the "father" of this property and I agree that this datatype is not the best. But I am not sure "monolingual text" is the best option. I used this for example as "Stockholm" as short name for "Stockholm City" and "Stockholm Municipality". I am not sure monolingual Stockholm would be a good option in for example Portuguese or Finnish, since they use other names for this entity. Observe that I have never proposed that this property should be used for abbreviations like United Kingdom/UK, rather for when you write "Municipality: "[[Stockholm Municipalty|Stockholm]]" in templates. The use should then be something like [[<WD-sitelink>|<WD-prop 743>]] instead of [[<WD-sitelink>|<WD-label>]] in the code in our templates. This especially when the "short name" is not identical with the "label", something I experience problems with in the Swedish language. Look for example in sv:Template:Jönköpings län 1952 where you find two entities with the same short name "Vetlanda" but who has different official names "Vetlanda landskommun" and "Vetlanda stad". Add to that "Vetlanda köping", "Vetlanda municipalsamhälle", "Vetlanda kommun", "Vetlanda församling", "Vetlanda socken", "Vetlanda distrikt" and the urban area of "Vetlanda", and you see some of my problems. The long names here are the official (with maybe some exception) but the full official names are not always used our templates. -- Innocent bystander (talk) 11:58, 2 November 2014 (UTC)
Delete in favor of datatype change. Having language of work or name (P407) for entities like NATO or the European Union doesn't make much sense, considering that they have multiple official languages. You can't correspond a short name to a specific language without using language of work or name (P407) as a qualifier for the short name. I don't see an advantage using this method over using monolingual datatype. —Wylve (talk) 15:50, 14 November 2014 (UTC)
Sounds like most of you talk about this property as an "abbreviation"-property. It was never proposed or intended as such! A mono-lingual datatype does not fit the purpose of the property. You need a multi-lingual datatype. -- Innocent bystander (talk) 09:56, 3 December 2014 (UTC)
Comment the shortening (abbreviate, contract, reduce or whatever) of a word *is* language-dependant. Coca Cola is shortened as « Coca » in French, as « Cola » in German, as « Coke » in English, etc. European Union is abbreviate as EU in English and German but UE in French. On United States of America (Q30), P743 (P743) is « USA » but USA is English (and for the irony : English is *not* the official language of USA), in French, the short name is « États-Unis ». And so on. @Vlsergey said the language if obvious but it isn't, 東京 is both Japanese and Chinese (Hant) but 东京 is Chinese only (Hans), and it's the same place! and what about multilingual context? For Switzerland − where there is 5 official/national languages − which one is obvious? As Wylve said, French *and* English are *both* official languages of NATO/OTAN, which one is the obvious one and which one should be prefered ? Plus, it's not only about « officiality », sometimes there is both an official full name and a official short name. If we need this property to be multilingual, why not add the ISO 639-2 code « mul »? Cdlt, VIGNERON (talk) 22:03, 4 January 2015 (UTC)
Latest comment: 9 years ago34 comments13 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Comment - This is as redundant as "lake type" and "mountain type". The item USS Ronald Reagan [5] has both "instance of = Nimitz-class aircraft carrier" AND "ship class = Nimitz-class aircraft carrier". Same duplication "Soviet aircraft carrier Admiral Gorshkov (Q359024)" with "Kiev-class aircraft carrier". Below are some numbers to show that currently the values are not consistent:
"claim[289]" - 912 items
"claim[31:(tree[11446][][279])]" - 28,323 items (instances of "ship" or one of its subclasses)
"claim[289] and claim[31:(tree[11446][][279])]" - 857 items - inconsistency, should be 912
"claim[289] and claim[31]" - 895 items - inconsistency, should be 912
"claim[289] and noclaim[31:(tree[11446][][279])]" - 55 items - inconsistency, should be zero
"claim[289] and noclaim[31:(tree[11446][][279])] and claim[31]" - 38 items - inconsistency, should be zero
Keep This one is not as clear as lake type. Ship class is a characteristic expected to be displayed in WP infoboxes; classes should be readily available from WD - I mean, not any type of ship, but specifically a class of ship. First, there are a set of specific constraints (see Property talk:P289); second, there are hundreds of classes of ship but not all ships belong to formally defined ship classes. As a result, a given ship may be instance of (P31) = something that is not a ship class... for example, currently
that is a misuse of instanceOf. InstanceOf has to be as precise as it can, so I changed it to "Sverige class coastal defence ship". "Sverige class coastal defence ship" is a subclass of "coastal defence ship". ANY "Sverige class coastal defence ship" is ALSO A "coastal defence ship" - here it is even reflected in the English language title, the string "coastal defence ship" is also contained in "Sverige class coastal defence ship". String matching aside, the information that the ship is a "coastal defence ship" is found upwards in the classification tree. That is exactly the same for lakes, mountains, cars, air planes, ...
my fix to the item fixes your second point, "there are hundreds of classes of ship but not all ships belong to formally defined ship classes. As a result, a given ship may be instance of (P31) = something that is not a ship class... for example" now P31 gives a ship class. Andrea Shan (talk) 01:55, 25 November 2014 (UTC)
BTW I find it quite impolite that you elect to "fix" the item that I chose as an exemple. Not that I do not agree with your change, but I was using it as an example, you see?
@Laddo: An invalid example. Anyone could have fixed it. I find it impolite that you find it impolite if editors fix items. Regarding WP infoboxes figuring out what to display - at the Wikidata item I cannot find a value for a ship class for that ship. So, yes, if there is not value for X than WP infoboxes may have a hard time to figure out what to display - if they are unable to figure out to display no value for X as empty string or "unknown" or something similar. Andrea Shan (talk) 02:30, 25 November 2014 (UTC)
Comment The documentation contains an error, since USS Enterprise is not a watercraft. Also, the property name is misleading, since the property is applied to submarines, which are not classified as ships in Wikidata. So the valid another consistency test is, after some fixing: "claim[289] and noclaim[31:(tree[1229765][][279])]" returns four items [6], all are described as fictional spaceships/starships. Andrea Shan (talk) 02:55, 25 November 2014 (UTC)
I changed the example, even if it may be too much simple. I'm not expert on ship, but I followed this and the previous discussion and ontologically I'm right with the distinction between the two classifications as explained by Laddo. I have seen some items of ships and in most of the cases the statements of P31 and P289 are the same: the two hierarchies need to be fixed. In this situation it is obvious that someone ask the deletion of P289. --Paperoastro (talk) 21:54, 26 November 2014 (UTC)
@Paperoastro, Esquilo: Could you take a look to Help:Item_classification ? I try to explain why this is not a misuse. Could you read and we can discuss what is unclear and needs to be clarified. If we later all agree maybe we should asopt this page to shorten the future discussions and to help everybody :) TomT0m(talk)20:12, 26 February 2015 (UTC)
There is no ontological difference between a "ship class" and a "ship type". A given instance of a ship like HMS Ven is indeed an instance of (P31) a ship class, e.g. Koster-class mine countermeasures vessel. That ship class is ontologically a subclass of (P279) another ship class, e.g. mine countermeasures vessel and so on up until ship (Q11446). "Ship class" and "ship type" are domain-specific versions of instance of (P31); they just indicate different ranks in ship taxonomy.
And like rank-specific 'type of' properties from biological taxonomy, this one should also be deleted. Consider this comment from the request for deletion of 'watercraft type':
Note how P71 and the other properties there all have labels like "(OBSOLETE) family (P71)" or are deleted, except for P31. While I differ with WikiProject Taxonomy in certain basic aspects of their approach to classification, they were utterly correct in deprecating those biological analogs of "ship class".
This debate has already been settled. Use WikiProject Taxonomy's solution and apply an 'ontological rank' property to determine the desired subclasses of 'ship' to show in a given infobox. Fortunately, ships are a relatively small domain and vessel class (P289) is not used on any Wikimedia client site per Property_talk:P289. Let's finish migrating the data away from this redundant 'type of' property, delete it, and use instance of (P31) as a generic solution for classifying this kind of thing, like the rest of the Semantic Web. Emw (talk) 04:33, 28 November 2014 (UTC)
I stand by my conviction that deleting such properties makes the use of Wikidata much more difficult to use as a source of data and therefore is contraproductive. /ℇsquilo08:14, 28 November 2014 (UTC)
Does User:Esquilo care to prove that there is no ship that is an instanceOf "Landsort-class mine countermeasures vessel"? That "Landsort-class mine countermeasures vessel" is a class of ships is already in the name. Is Are ship classes, classes without instances? What do they class then? Andrea Shan (talk) 15:41, 30 November 2014 (UTC)
Esquilo, when I say "there is no ontological difference between a 'ship class' and a 'ship type'", I mean more precisely that any given ship class or ship type is -- in the terms of ontology -- a class. They are merely different ranks in a ship taxonomy. Yes, a ship like HMS Ven may change its "ship class", but that does not entail that it is not an instance of a given "ship class" at any given time. Whether it is a good idea to use instance of here is a question on which reasonable people might disagree, but given that Koster-class mine countermeasures vessel is a subclass of mine countermeasures vessel, whether HMS Ven is an instance of Koster-class mine countermeasures vessel is not a matter of debate among people familiar with ontology.
Your assertion that "HMS Ven" could be said to be a member of "Koster-class mine countermeasures vessel" further indicates a lack of familiarity with basic membership properties. For example, "John Lennon instance of male" is correct but "John Lennon member of male" is not. Similarly, HMS Ven could be said to be a member of Swedish fleet (Q10685327), but to say "HSwMS Ven (Q10515240)member of (P463)Koster-class mine countermeasures vessel (Q10548373)" is an elementary mistake.
Keep "ship class" (P:P289): A defined property seems more appropriate for this. Makes it easier to maintain as well. Things in P:P31 tend to be mixed up and not necessarily better maintained. --- Jura13:28, 30 November 2014 (UTC)
"A defined property seems more appropriate for this" - does User:Jura1 care to explain in how far rdf:Type is not a "defined property"? Does Jura1 care to consider that "Things in P:P31 tend to be mixed up and not necessarily better maintained." can be true along with "Things in P:P289 tend to be mixed up and not necessarily better maintained."? If one can insert the IDs of each property into a phrase, how can such a phrase be used to vote for one property? Andrea Shan (talk) 15:22, 30 November 2014 (UTC)
Comment Among millions of products that exist, and further millions of physical items made without human labor, "items" in subClass "ship" are deemed that special by four users, that they are the only items to get their own property for classification. Some even promote misuse of instanceOf. Andrea Shan (talk) 15:36, 30 November 2014 (UTC)
Redefine: A ship class (Nimitz, Dreadnought, Concordia, Flower, etc) is just a name that is used by humans to group individual ships of specific types (aircraft carrier, battleship, cruise ship, corvette, etc). A specific ship need not belong to any class but will always have a type. The foregoing being true, then I suggest that this property P289 is incorrectly defined because it combines class name and ship type into a single value when the two should be kept separate and only be combined at the point of use.
This last is important, not only because ships need not belong to defined classes, but also, because when used in final article form, the combination of ship class and type must be properly styled and, depending on use, hyphenated or not hyphenated. Ship classes named for a member of the class are italicized: Nimitz class when the compound term describes the class and: Nimitz-class aircraft carrier when the compound term describes the ship type. When a ship class is not named for a member of the class, the same hyphenation rules apply, but the class name is not italicized: Flower-class corvette. All of this is presentation detail which is not something that Wikidata should concern itself about.
If P289 is allowed to stand as is, users of the data, in order to provide correct presentation, must disassemble the property value to apply appropriate styling and hyphenation. P289 should be redefined to be just the class name. The ship's type should be provided by another property.
Yes, but why force subscribing wikis into doing that derivation or extraction?
At enwiki, the meta thing commonly called a ship class is a construct built from one or more primitives:
<class name>
<class name> markup
connective text <class> or <-class>
<ship type>
optional parenthetic <class name> disambiguator
optional nationality <class name> disambiguator
optional parenthetic <ship type> disambiguator
I can't speak for other wikis which may do things differently, but at enwiki, we already have the tools necessary to assemble and render a correctly formatted meta ship class for all of the above except those few that require the optional nationality disambiguation (British Porpoise-class submarine disambiguated from United States Porpoise-class submarine).
Don't make those tools obsolete by lumping all of these primitives into a single property.
Keep I really can't say it better than has been said above but it seems clear to me that we should maintain the distinction of instance of and ship. Otherwise it seems to me that the instance of a vessel, would be ship, submarine, etc. This would also make instance of a huge unwieldy mess with too many tangential associations that would skew its usefulness into a "Stuff" category. Reguyla (talk) 20:13, 10 March 2015 (UTC)
In the vast number of instances where I personally used the class rather than the type of ship, I had maybe one, maybe two cases where it was not evidently clear that the type of ship could not be derived from its ship class (with the appropriate relationships). Have you not actually worked with the data? --Izno (talk) 23:27, 10 March 2015 (UTC)
Although I am fairly new to Wikidata I have worked with ship articles often in the past. I do agree that in general most ships classes are evident but there are also a number of cases, particularly with older vessels, where this is not evident. At the end of the day I really don't feel that strongly about it but it doesn't seem like an ideal solution to be to get rid of this property. Reguyla (talk) 13:45, 11 March 2015 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Latest comment: 9 years ago26 comments13 people in discussion
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.
In tennis, most players have two rankings simultaneously, one for single play, and one for double play. As far as I'm aware, for mixed-double there is no ranking, therefor that property has not been requested. I would support the creation of a new property "sports ranking" that might be useful in other sports, but for tennis we would need these two anyways. Edoderoo (talk) 22:50, 19 April 2014 (UTC)
There is probably as many ranking that there is sport organisations. I would propose to use a generic ranking properties with a qualifier to precise of which ranking we are referring to. TomT0m(talk)09:42, 20 April 2014 (UTC)
Can we still show these two distinct values separately in an infobox? As this is not stored just for fun, but to be used in a tennis infobox. Edoderoo (talk) 16:59, 26 May 2015 (UTC)
Question I agree 100% with this deletion request, .. however ... as I understand it, Wikidata Client cant access qualifiers at the moment, so there is no way for infoboxes to differentiate between two values for the same property..? If so, I think Wikidata's duty to be useful for infoboxes means this deletion should be put on hold until Wikidata Client allows properly structured data. John Vandenberg (talk) 07:03, 25 April 2014 (UTC)
Question As ranks change, how would the history of both rankings be mixed in one property? --- Jura15:29, 10 May 2014 (UTC)
Jura: Use sport (P641)=<singles tennis> and start time (P580) as qualifiers to note when a singles ranking was first achieved and end time (P582) when it changed. Similarly for doubles. This means a tennis player might have twenty values for this property, each with three qualifiers. Mark both the current values (singles and doubles) as 'preferred' Filceolaire (talk) 20:19, 30 May 2014 (UTC)
Though "singles tennis/doubles" is not a "sport or discipline" (btw those words means almost the same in Finnish), but "tennis" alone is. --Stryn (talk) 17:15, 23 June 2014 (UTC)
But in the item you linked, there's "sport: table tennis", then in tennis player items it would be "sport: singles tennis"? Also table tennis can be played as doubles (though I don't know if they have a ranking for doubles). Anyway, then we should create items for singles tennis and doubles tennis, if they don't exist yet. --Stryn (talk) 14:30, 26 September 2014 (UTC)
Just came in my mind: how about ITF junior/senior/wheelchair rankings (from ITF website)? I think that we should add them also. If so, then we should keep this property. --Stryn (talk) 21:20, 9 December 2014 (UTC)
Comment I haven't followed tennis for many years, but I think it used to be two ranking-systems for double. One for each player and one for each combination of players. Each player could then have several double-rankings. One for him/her alone and one for every partner (s)he had. -- Innocent bystander (talk) 10:02, 6 March 2015 (UTC)
You're correct. I would be very happy if someone (who didn't take part in this discussion) could already close this as this has been open for over one year and so making us stuck to make updates :( --Stryn (talk) 17:51, 8 June 2015 (UTC)
I am closing the thread now! I know, I have discussed in the the thread above, but I think anybody who has been involved in the discussion can see a clear consensus. Technical solutions are now available that makes it easy to replace the properties. -- Innocent bystander (talk) 07:12, 9 June 2015 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Latest comment: 9 years ago11 comments9 people in discussion
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.
As the proposer, I don't object deletion if the idea is to use heritage designation (P1435) for all heritage (although someone could've notified me about this request), just please make sure to migrate all the uses before deleting - my bot requests tend to be ignored. Thank you. — YerpoEh?08:26, 24 February 2015 (UTC)
Tanks Yerpo. Il beleived by the form of the deletion request that you where directly notified. Il will do directly next time on the page of people who voted for the property. --Fralambert (talk) 23:15, 26 February 2015 (UTC)
@Pigsonthewing: The generic/specific properties will probably like a "chicon/endive" debate in frwiki, it will be eternal and come back time to time. I also beleive there is a uge difference between a item and a string property on the generic/specific debate. For the case of P1597 (P1597), it is mosty the same property that heritage designation (P1435)}, but only for Slovenia. I am not sure a item property for only one country sould be alowed. But there is plenty of string properties who use national databases. --Fralambert (talk) 20:39, 1 May 2015 (UTC)
Delete I agree with Fralambert that the issue is very different from string-type identifier properties. Centralizing work in a generic "heritage property" appears to work quite well. @Ricordisamoa, Pasleim:, you have done similar jobs in the past, would you do the migration ? --Zolo (talk) 13:03, 12 May 2015 (UTC)
Latest comment: 9 years ago5 comments4 people in discussion
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.
Proposal: convert data type of property "IPA" from string to monolingual string.
We need to indicate the language IPA refers to. Even if it's not ideal, the data type "monolingual string" has a feature for that. --- Jura08:02, 16 February 2015 (UTC)
Oppose. I oppose this property existing in the first place, as it's very clearly Wiktionary-oriented linguistic data rather than actual data regarding the entity, but if it is to exist, it shouldn't be misusing the monolingualtext datatype to indicate the language of something other than the string itself. Use a qualifier instead. --Yair rand (talk) 10:41, 24 February 2015 (UTC)
If the entity is a word the pronounciation is clearly a property of that word. Thats also true if you think of place names like Versailles in the US. I have mixed feelings about the conversion, because while I think that really the IPA string itself is in a certain language, the pronounciation is regionspecific as well as language specific.--Saehrimnir (talk) 05:43, 22 April 2015 (UTC)
Keep. Saehrimnir, Yair rand No wikidata entities are words however a wikidata may have statements that refer to a word (e.g. official name (P1448)). This property is worth keeping provided it is only used as a qualifier to those properties. As such the IPA doesn't need to be tied to a language though the word it is describing may well need to be. Filceolaire (talk) 20:29, 23 April 2015 (UTC)
Latest comment: 9 years ago16 comments11 people in discussion
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 for now. Can be reconsidered when the 'number with units' datatype is available. --Pasleim (talk) 16:16, 17 May 2015 (UTC)
This property should not restrict the units in which its values are given. This property should be named "tempo" and with the datatype of quantity with units as opposed to number. "Beats per minute" is a unit of tempo, not the physical quantity itself. Using "beats per minute" on music instead of "tempo" would be analogous to using "maximum kilometers per hour" for an airplane instead of "maximum speed". Not all music use "beats per minute" as a measurement of tempo and not all references to statements will use bpm. —Wylve (talk) 05:08, 8 March 2015 (UTC)
Keep until the new datatype is here where it can be smoothly converted to a "tempo" property. I know this cannot influence the result of this discussion but I worked hard the other day adding this property to items. --AmaryllisGardenertalk13:40, 8 March 2015 (UTC)
Wrong, the unit is min-1 like frequency. You can count per minute or per second so you should be able to distinguish between different types of measure. – The preceding unsigned comment was added bySnipre (talk • contribs) at 14:25, 11 March 2015 (UTC).
I think you are mssing each others point Beats per minute is the unit therefore you only give the value as number. So its not strictly speaking a property the property would be tempo or frequency which than would need a unit which we don't have at the moment. also see below.--Saehrimnir (talk) 06:14, 22 April 2015 (UTC)
Delete We have to create a general property for all frequency measurements (revolution per minute in case of motor, oscillation for wavelength,...) so the best is to create one frequency property as numeric datatype and to use it in music field like in other fields. Snipre (talk) 14:25, 11 March 2015 (UTC)
I actually don't agree with the comment regarding a general property, but that's not a discussion for here (primarily that revolutions for example are not dimensionless). --Izno (talk) 21:27, 11 March 2015 (UTC)
Izno Please give arguments: it is always easier to understand the position of each contributor with some argumentation. Then take the definition of frequency: "Frequency is the number of occurrences of a repeating event per unit time" see here. In mechanics we speak about rpm (revolution per minute) and in music about bpm (beats per minute) but at the end this is the same kind of measurement: beat and revolution are not units, there are events. The question is then if we need to create different properties for each way to use a measurement. My question is then what is the problem to use frequency for music ? Just a small comment in the project music and on the property page saying that this property is used in music to describe the tempo. Using this system we give once the opportunity to musicians to understand what is bpm in term of scientific and standard definition.
Then if we use WP to understand a little more about bpm, you will find that bpm is a unit of tempo (see here). So the minimal thing is to create a property tempo as numeric data type if you don't want to use a frequency property. Snipre (talk) 13:00, 12 March 2015 (UTC)
I think there should be a property name than some way to define which physical quantity this represents and then the unit like its now already with time but this only having specific hardcoded units. But in any case deleting this requires the datatype number with unit, because it does not help to delete this property now but all the frequency properties should be merge once this is possible. -Saehrimnir (talk) 06:03, 22 April 2015 (UTC)
@Saehrimnir: We don't need the datatype number with unit to DECIDE the deletion of the property, we need the datatype number with unit to REPLACE and DELETE. --Snipre (talk) 14:49, 10 May 2015 (UTC)
Keep for now. Reconsider when the 'number with units' datatype is available and we can see if we can have a 'bpm' unit or if we have to use Hz. Filceolaire (talk) 16:56, 11 May 2015 (UTC)
Latest comment: 9 years ago7 comments4 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Comment Oh thanks Filceolaire proposing this. I don't oppose this, but please wait. Even if we delete this, I think it is better to delete after the discussion settled and bot did work (e.g. coping the data to other section). Now we are discussing about "in what format we should save these data" from technical point of view (at property proposal linked above and Wikidata module talk page). --Was a bee (talk) 18:58, 20 March 2015 (UTC)
Not a problem. These deletion discussions can take months and even after a decision to delete is taken the property is not deleted until all the statements using it are deleted first - we just change the property name to add "(deprecated)". Filceolaire (talk) 17:21, 22 March 2015 (UTC)
Latest comment: 9 years ago2 comments2 people in discussion
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.
Latest comment: 9 years ago2 comments1 person in discussion
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.
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.
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Properties for events and their dates and locations
Latest comment: 9 years ago43 comments15 people in discussion
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)
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.
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.
Comment @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)
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)
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)
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)
@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)
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. --- Jura11:58, 5 December 2014 (UTC)
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)
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. --- Jura07:37, 6 December 2014 (UTC)
@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)
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)
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)
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)
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)
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)
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)
@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)
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)
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)
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)
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.
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)
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
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)
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)
@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.
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: [8]. — Ivan A. Krestinin (talk) 20:54, 7 April 2015 (UTC)
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)
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)
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.
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)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Latest comment: 9 years ago4 comments3 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
A 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)
Latest comment: 9 years ago17 comments13 people in discussion
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.
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)
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:
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)
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.
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)
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)
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)
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)
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)
Latest comment: 9 years ago6 comments6 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Comment personally I'd tend to keep it, but it seems only rarely used and its proposer thinks it should be deleted. --- Jura17:22, 9 January 2015 (UTC)
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)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Latest comment: 9 years ago17 comments13 people in discussion
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.
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)
"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)
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)
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)
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)
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)
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)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Latest comment: 9 years ago20 comments10 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Delete 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*talk12:24, 2 May 2015 (UTC)
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)
Wtf? The item you linked is a language, not a station. How can a station have multiple station codes? -- Bene*talk09:22, 5 May 2015 (UTC)
@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*talk09:24, 5 May 2015 (UTC)
The "station code" property is about stations, not languages. The discussion about languages is offtopic and does not belong into this RFD. -- Bene*talk20:07, 5 May 2015 (UTC)
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)
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)
@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*talk12:14, 5 May 2015 (UTC)
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*talk20:11, 5 May 2015 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Latest comment: 9 years ago7 comments5 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
This 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)
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)
@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)
Latest comment: 9 years ago3 comments3 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
This 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)
Latest comment: 9 years ago16 comments7 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Please give the difference because there is no huge difference in the descriptions, at least in English. Snipre (talk) 15:53, 20 May 2015 (UTC)
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)
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)
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)
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)
@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)
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)
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.
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)
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)
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.
Latest comment: 9 years ago7 comments6 people in discussion
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.
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)
Latest comment: 9 years ago8 comments4 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
I 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. --- Jura12:55, 29 August 2015 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Latest comment: 9 years ago9 comments6 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Delete 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.----- Jura06:48, 19 August 2015 (UTC)
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)
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)
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%? --- Jura02:45, 20 August 2015 (UTC)
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 edits12:49, 20 August 2015 (UTC)
This is correct, no such argument has been made, but otherwise we wouldn't be editing statements here, wouldn't we? --- Jura13:35, 20 August 2015 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
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. --- Jura07:31, 13 September 2015 (UTC)
Latest comment: 9 years ago13 comments11 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
I 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)
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)
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)
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. --- Jura05:00, 21 August 2015 (UTC)
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)
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)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Latest comment: 9 years ago7 comments6 people in discussion
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.
Latest comment: 9 years ago2 comments2 people in discussion
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.
Latest comment: 9 years ago9 comments7 people in discussion
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.
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. --- Jura04:45, 21 August 2015 (UTC)
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)
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)
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)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Latest comment: 9 years ago15 comments8 people in discussion
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.
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)
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)
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)
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)
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)
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)
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)
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)
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 [14]. 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)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Latest comment: 9 years ago2 comments2 people in discussion
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.
Latest comment: 9 years ago4 comments4 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Keep 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)
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)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Latest comment: 9 years ago12 comments11 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Delete Redundant, 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)
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)
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)
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)
Latest comment: 9 years ago5 comments4 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Please help converting to the new property. Property to be deleted once it's no longer in use/replacement functional. --- Jura15:50, 19 November 2015 (UTC)
The monolingual datatype doesn't provide a list of languages with all possible languages and with an unknown language for special cases. Then the conversion from P387 to P1683 required unknown language because we can't automatically detect the language from claims using P387. Snipre (talk) 16:26, 18 November 2015 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
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 (talk) 15:35, 8 December 2015 (UTC)
Latest comment: 8 years ago9 comments6 people in discussion
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.
They seem to be different, but to me it's not entirely clear which code they're supposed to be. There are several code systems for railway station (UIC, IBNR, IFOPT, german railway (DS100, including stations from other countries), swiss railway (DIDOK, including stations from other countries), austrian railway, …) out there. My guess is that station code (P296) is something russian, P722 is either UIC or IBNR and P1655 something korean. So we need a clarification on them and new properties for the remaining code systems. --Nenntmichruhigip (talk) 22:57, 11 February 2015 (UTC)
Delete. station code (P296) is meant as a generic property with qualifier 'catalog (P972)' to specify which station code system applies. Stations can therefore have multiple codes as long as these have different values for the qualifier. This means UIC station code (P722), P1655 (P1655), IBNR ID (P954), MTR station code (P1377) are redundant and can all be deleted. Alternatively we need to create codes for every system of station naming (thousands?) in this case we definitely need to keep station code (P296) and add "subproperty of:station code" statements to all the specific properties in the hope that at some time in the future we can query for statements using "station code;including subproperties" so we don't have to know what the special property is in order to get the station info. Filceolaire (talk) 01:11, 2 May 2015 (UTC)
But then P296 would have to be altered accordingly. I'll list the affected properties here, feel free to add others to the list: --Nenntmichruhigip (talk) 15:13, 2 May 2015 (UTC)
Latest comment: 8 years ago7 comments5 people in discussion
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.
Yes, it could be done that way. My thinking was that as the Pokémon Browser number is a String and that the existant values are still valid (they all have a qualifier), we could merge the Pokédex number in P1685 and rename it to Pokédex number. That would save some work moving all values (we'll only have to do some). Ebe123 (talk | contributions) 22:59, 1 February 2015 (UTC)
Retrospectively, I think I shouldn't have supported the creation of Pokémon index (P1685) as it's actually more efficient to have separate properties for each numbering scheme.
For this property, string would be the datatype we use for these. So yes, support deletion and re-creation with that type. --- Jura07:21, 5 February 2015 (UTC)
I don't know if it would be good to merge both properties into one with text-type because normal Pokédex numbers are unique in every dex a number is unique, while in Browsers there is an other system with letters with not unige numbers. Furthermore, there are more possibilities to make mistakes by editing. --MGChecker (talk) 14:42, 7 June 2015 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Latest comment: 8 years ago8 comments8 people in discussion
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.
Latest comment: 8 years ago10 comments7 people in discussion
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.
@Pasleim: It is too early to delete properties because too few items or no item are using them. WD is in some sleeping mode because too few WPs are using the data mainly because of some development reasons. We have to wait at least until the implementation of the arbitrary access is finished and after the development of the first infoboxes using mainly WD as data source is lauching to start the purge of properties. Snipre (talk) 15:58, 20 May 2015 (UTC)
@Snipre: I'm not requesting deletion because of too few items using them, otherwise I could request deletion of 271 properties (17% of all properties!). That's the current number of properties with 5 or less usages. But P659, P857 and P1152 are different, as they can't even be used and according to the talk pages nobody realized it. --Pasleim (talk) 13:09, 22 May 2015 (UTC)
Support deletion: as they are not being used, can't be used and nobody (other than Pasleim) tried to use them. --- Jura05:44, 21 May 2015 (UTC)
Latest comment: 8 years ago21 comments6 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Keep This 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 edits22:57, 30 May 2015 (UTC)
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 edits16:48, 31 May 2015 (UTC)
It's no big deal to delete this. I'm sure we will be able to sort it out eventually. --- Jura06:33, 1 June 2015 (UTC)
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)
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)
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 edits11:41, 3 June 2015 (UTC)
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)
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. — billinghurstsDrewth04:26, 10 November 2015 (UTC)
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 edits13:57, 25 November 2015 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Latest comment: 8 years ago4 comments4 people in discussion
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.
Doesn't box office only refer to ticket sales in cinemas (i.e. the box office sales) and not the total revenue? - Nikki (talk) 11:46, 18 October 2015 (UTC)
Latest comment: 9 years ago5 comments5 people in discussion
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.
Question Does every drug have 7 different names? If so, then multilingual datatype is maybe something we should consider in the future? Not to encourage every name to be translated to icelandic, but to give better space for all of these 7 languages. -- Innocent bystander (talk) 13:41, 21 October 2015 (UTC)
@Innocent bystander: We are speaking about WHO INN only not about commercial names or common names. So there is only 7 translations of WHO INN. For other names we are using aliases and we wait for the multilingual datatype for the IUPAC name because there is a translation for IUPAC name in each language.
Change datatype to monolingual text. If the WHO identifies each name as being associated with a particular language then we need to record that language info and a monolingual text datatype is the best way to do it. If needed this property can have 7 values - one for each of these languages. Joe Filceolaire (talk) 20:55, 25 October 2015 (UTC)
Support But we have to first create the new property with monolingual datatype and transfer the current data before deleting the current property. Snipre (talk) 15:46, 27 October 2015 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Latest comment: 8 years ago12 comments5 people in discussion
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Keep There's a clear description of what this property relates to at en:Vice-county. Given that even the primary located in the administrative territorial entity (P131) designations are so far only very poorly populated for places in the UK, it seems premature to delete this solely because the data hasn't yet been filled out. One question, though, for @Pigsonthewing: what is the scope ultimately intended for this property? Is it anticipated that it will be applied only to nature reserves, sites of particular biological interest etc? Or, is it intended that it should be filled out for every civil parish (Q1115575), and relevant places in a biological vice-county will be identified via their civil parish? Or, would it ultimately be envisaged to roll it out to all locations in the UK and Ireland? Jheald (talk) 12:44, 21 October 2015 (UTC)
I can only see the sample given with the proposal was added when it was created 5 months ago, but there is no practical use. Where do you see any? As for the nomination, I used the script. If you failed to get the notification, would you file a bug report? --- Jura13:54, 21 October 2015 (UTC)
No: if you're using a script and it's not working as it should, then you should raise a bug; being in a far better position than I am to describe the circumstances. But thank you for acknowledging that the property is not unused. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits19:30, 23 October 2015 (UTC)
"But thank you for acknowledging that the property is not used." at least you agree on something. As for the script, it's the standard one. From my side, it worked fine. Maybe what appears as a bug to you is a feature, the property being unused. --- Jura14:29, 27 October 2015 (UTC)
It also failed when you used it, I presume, since it doesn't seem to have ever worked for anyone (I first saw it pointed out months ago in #officeholder_.28P1308.29). In Special:Diff/268213984 I removed the misleading parameters. If someone wants to re-add them and make it all work properly, they can, but at least for now it will stop people from being led to believe that the template will cause people to be pinged when it won't. - Nikki (talk) 01:18, 5 November 2015 (UTC)
Question @Micru: How is "in the jurisdiction of" different than located in the administrative territorial entity (P131)? And how is "contains jurisdiction" different than contains the administrative territorial entity (P150)? --Closeapple (talk) 10:59, 7 July 2014 (UTC)
Neutral on deletion of P1001 specifically. (My only knowledge is about the suggested replacements.) --Closeapple (talk) 11:51, 7 July 2014 (UTC)
Oppose deleting applies to jurisdiction (P1001) only to replace it with a new property which is also called 'applies to jurisdiction'. If the P1001 is being used where located in the administrative territorial entity (P131) or contains the administrative territorial entity (P150) are more appropriate then ammend the description to make it clearer how it should be used and add some aliases to P131 and P150 so they show up in searches for 'jurisdiction'. If there is a real use case that isn't covered by these three existing properties then propose the creation of that additional property. Nothing you have said above justifies the deletion of P1001. Filceolaire (talk) 08:14, 10 July 2014 (UTC)
Delete With merge with p:p518 in a general property "applies to". Snipre (talk) 12:41, 9 July 2014 (UTC)
Keep I don't think applies to part, aspect, or form (P518) can alter this... — by Revicomplaint? at 10:34, 3 August 2014 (UTC)
Keep The settlements are not parts of the municipality. P1383 is similar to contains the administrative territorial entity (P150), but P150 is restricted to administrative units. I propose to extend P150 to all settlements, not only administrative units. has part(s) (P527) is not the right property. --JulesWinnfield-hu (talk) 13:01, 15 August 2014 (UTC)
Support
Comment I just created title (P1476). --Jakob (talk) 00:40, 18 September 2014 (UTC)
Deleted Hazard SJ 01:37, 19 January 2015 (UTC)
Delete per nom. George Edward C – Talk – Contributions 16:27, 25 January 2015 (UTC)
Comment @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)
Awaiting a bot to clear the current cases. --George (Talk · Contribs · CentralAuth · Log) 17:04, 7 March 2015 (UTC)
WikiProject Molecular biology has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. --Tobias1984 (talk) 17:46, 11 May 2015 (UTC)