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 - no idea what Jura's referring to; it looks like series ordinal (P1545) is already being used on the months where they are described as subclasses so the data is there. I really don't think it is helpful to have a property like this that is entirely wikidata-internal and applies to only 12 items, there have to be other ways to do it. I would question the creation process on this one. ArthurPSmith (talk) 14:45, 4 August 2016 (UTC)
@Jura1: during the property proposal, you mentioned that this property could be used by a (non-existent) script by me. As I don't plan to use this property, are there any other application where it is needed? --Pasleim (talk) 16:06, 4 August 2016 (UTC)
The property talk page links to a series of queries .. it works, but it would work better once integer datatype is available. Once it's available, I think we should convert it. --- Jura16:14, 4 August 2016 (UTC)
Thanks. I like the way you did the sections. BTW, it times out for me. Will we get integer-datatype anytime soon? --- Jura17:32, 12 September 2016 (UTC)
The change brought the query closer to time-out limit. I restored the use of this property. This should be converted to integer datatype once available. --- Jura19:11, 15 January 2017 (UTC)
Keep Given that there are probably many queries where it makes sense to look at this property and it increases the speed of those queries, I'm okay with keeping the property. ChristianKl (talk) 09:29, 5 June 2017 (UTC)
It's actually the opposite: it avoids using a qualifier on the somewhat random statement. --- Jura10:25, 7 January 2018 (UTC)
Delete In use ≠ cannot be deleted, we can just mark it as DEPRECATED, find a migration way and finally (i.e. migration is done) delete it. --Liuxinyu970226 (talk) 13:05, 29 November 2017 (UTC)
This is a horrible hack but I can vote keep if somebody can show me a query where using this bespoke property leads to substantial SPARQL performance savings. (I mean, fast inverse square root (Q32980) is also a horrible hack that gave crazy computational savings.) @Jura1, Pasleim: Can you give me two example queries that search for the same thing, but one uses the Wikidata month number hack and the other doesn't? Deryck Chan (talk) 19:46, 11 December 2017 (UTC)
One example is the above mentioned database report for people who died on their birthday [1]. I ran the query 10 times with and without the use of P2837 by preventing loading results from cache. On average, running time of the query with P2837 was 34.5s, without P2837 it was 38,1s. --Pasleim (talk) 21:56, 11 December 2017 (UTC)
@Pasleim: Hmmm... I wouldn't call that significant advantage. I'd say it needs to shorten the time taken to execute a certain class of queries by a factor of 2 to be worth having a property. Delete. Deryck Chan (talk) 20:47, 12 December 2017 (UTC)
The problem is that it's just today's value. These things keep timing out and there isn't actually a downside in having the property. --- Jura21:00, 12 December 2017 (UTC)
But if we take Pasleim's results as typical, there would be very few occasions on which using this hack would make the difference between timing out and not timing out. Deryck Chan (talk) 11:16, 21 December 2017 (UTC)
No I don't think so. If it was 16s vs 32s it would convince me, but 28s vs 32s isn't that significant. A 10-20% difference in runtime can be wiped out quite easily by a coincidental change in the backend algorithm. Deryck Chan (talk) 18:06, 21 December 2017 (UTC)
It was significant when the property was created. Timeout was at 30s and using this property made it possible. Given the basic information of this item, I don't think we should be using a qualifier on a statement that appears to be somewhat random. I think if information important information is encoded in the qualifier of a p31/p279, it's probably at the wrong place. --- Jura10:25, 7 January 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
My thought is that basically all external ID properties (for classes or properties) are potentially duplicates since you can add them as equivalent classes or equivalent properties respectively. They're functionally equivalent, for use in making SPARQL queries. One could add equivalent class statements to everything in Wikidata and make all external ID properties redundant. The only difference is that with the external ID, the format is consistent, whereas with the equivalent property purl, you can have multiple URI strings matching the same concept, which makes SPARQL queries inconsistent. For this reason I think the external ID property should stay. I'm not sure what makes this one special. I added the equivalent property statements while I was waiting for the RO property to be approved. Gstupp (talk) 21:43, 8 November 2017 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
This ID apparently doesn't have other use than being an ID for temporary web page for each of current 101 parliament members. This ID is not intended to be permanent. Each ID will be defunct (web page gone) as soon as person is no longer a parliament member. Currently 127 persons have this ID, so for 26 of them the ID is defunct or was defunct already at the time when added here, e.g. Q312894 or Q2621730. So storing these IDs here doesn't seem useful.--2001:7D0:88DD:F880:4C62:3A48:E43D:923713:41, 25 December 2017 (UTC)
Keep Although it does seem that the Riigikogu website no longer shows the member's profile page when they're no longer a member (and thus we might want to change the formatter URL (P1630)), these IDs can still be used to access information on what the member did whilst in office, e.g. their speeches (Q312894, Q2621730), or questions (Q312894, Q2621730). If a member leaves office, and then returns, they also appear to retain their earlier ID. --Oravrattas (talk) 13:46, 26 December 2017 (UTC)
I don't have special expertise here, but if the formatter URL can be changed to save this, that sounds like the best option. --99of9 (talk) 00:10, 27 December 2017 (UTC)
@Deryck Chan: sure, though it's not obvious to me which we should use. Is the idea simply that this should be any valid URL for people? Linking directly to, say, the person's speeches, might make it seem like that's what this property is about, rather than something more general. --Oravrattas (talk) 11:33, 25 January 2018 (UTC)
Delete. I've looked at the links that Oravrattas gave me and figured that while the identifier is stable, there doesn't seem to be a single formatter URL that works well for all current and former parliamentarians. Given that these IDs are actually longer than the member's names (I wonder if they're just hashes of the member's name) I'm becoming convinced that this ID isn't particularly useful for Wikidata. Deryck Chan (talk) 11:00, 20 February 2018 (UTC)
So you can still use this id after member has left, but I doubt if you should use it. The id seems to be hash of a the member's name or something similar indeed. For instance, first one of speech links above returns speeches attributed to "Juhan Parts" and "Majandus- ja kommunikatsiooniminister Juhan Parts" (Juhan Parts, the minister). Most of this person's speeches however are attributed as "J. Parts", and these are not returned as given hash is apparently equalent to "Juhan Parts". So, it seems that Riigikogu site doesn't use this id or hash as a real identifier. Speech entries or questions entries are not attached to particular person with particluar identifier. Should there be speeches attributed to different persons with the same name, then using the same id'd probably return speeches for both. 90.191.81.6515:24, 7 March 2018 (UTC)
The property has clear value whilst someone is still in office, and still has at least some value after they leave. That some speeches by a person aren't found by the ID doesn't seem like sufficient reason to delete the property. To the best of my knowledge there have never been two Riigikogu members with the same name. Should this ever happen, I strongly suspect that they would be aware of it, and capable of allocating a unique ID to the second person. Again, a fear that perhaps, in the future, an identifier might turn out to not be unique, does not seem like a suitable reason to remove a property that is currently useful. --Oravrattas (talk) 06:16, 22 March 2018 (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.
@Ash Crow: Delete if you want, but I object vehemently to this being called "on the sly". I am not a property creator. I proposed a property where properties are proposed; it got consensus there and was created. I didn't even know at the time that there was a WikiProject to inform...and if informing WikiProjects is a policy, it's not one I've seen before - if it's unwritten but you expect people to follow it, write it down!! If it is written down, I apologize, but it isn't exactly obvious to find: it's certainly nowhere to be seen on Wikidata:List of policies and guidelines, or Wikidata:Property proposal, or Wikidata:Property proposal/Header, orWikidata:WikiProjects... and while you're writing down guidance, please grab AGF from your more mature sister project. Swpb (talk) 20:29, 26 January 2018 (UTC)
Delete do you really call consensus the 1 (one) positive vote you got, after 9 days ? without any notificztion to the project that has been working on names for years, now ? - not easy to find ? even if you don't know about the project, the general use is to ask on Project Chat about what to use, or if there are already existing properties, before proposing the creation of a new property, which generally results in someone pointing to the appropriate project. You did not ask about anything, made a proposal, got the creation with 1 vote, without bothering whether other people could be concerned… and this property is clearly NOT USED, except on the very specific item you used as example. This is not collaborative work... and this property, as it is, is useless and unused. --Hsarrazin (talk) 20:34, 26 January 2018 (UTC)
Again, I didn't make the property, and I didn't decide what level of consensus was needed! Take that up with User:GZWDer. (But yes, a decision with no opposing voices is a consensus, by definition, even if a provisional one – another thing your sister projects settled a long time ago.) But again, more about this mysterious "general use". Where the hell is any of this written down? If someone with a decade on Wikipedia can't see what's expected, how on earth is a total new person supposed to figure your project out?? I thought hostility to new users was bad on Wikipedia, but this project takes the cake. Not only are your procedures all of the form "we don't say so, but everyone knows it" - but when someone doesn't know it, the immediate assumption is that they're malicious! (See: "sly") You could not possibly shoot the viability of your project in the foot any harder than by acting like you are. Swpb (talk) 20:47, 26 January 2018 (UTC)
I didn't tell you are a property creator. My problem is more with the actual creator of the property (who created it rather quickly with only one vote) than with your proposal. As for the Wikiprojects, they are mentioned in the FAQ. If you come from another Wikimedia project, the weight given to consensus on wikiprojects can indeed be confusing, but as a very generalist project in multiple language, they provide a very efficient way to notify all people working on a particular topic. As for the part you "object vehemently": English is not my native language, so the expression may have stronger undertone than what I intended (I had to use Linguee to translate it to English) - what I wanted to say that it went under the radar. -Ash Crow (talk) 21:30, 26 January 2018 (UTC)
If someone with a decade on Wikipedia can't see what's expected, how on earth is a total new person supposed to figure your project out??… well, like on any project : Ask the Project chat (whatever it is called on any project), which you did not ! --Hsarrazin (talk) 09:11, 27 January 2018 (UTC)
@Hsarrazin: Swpb (talk) 14:45, 1 February 2018 (UTC) Now you're going in circles: How could anyone know there was a question to be asked in the first place? Nothing I've ever come across would suggest this particular question! In fact, I still have not been shown where this "ask a WikiProject first" rule is written down, because it isn't, anywhere. I dare you to acknowledge that simple fact. Your project's documentation is embarrassingly lacking, and you're doubling down on defending the indefensible. I've pointed to at least four places where this supposedly well-known guidance should appear explicitly; you could apply your combative energy to making sure it does, instead of attacking people for not being mind-readers. That's assuming your goal here is to make a better project, instead of making yourself feel smart while driving valuable contributors away as fast as possible. Swpb (talk) 14:05, 29 January 2018 (UTC)
Delete. Property created without consensus, duplicates the existing common usage without a "good selling point". Tpt (talk) 20:51, 28 January 2018 (UTC)
@Jura1: I didn't request it, I just commented the one time. It sounded like the proposer had a use case for it, but if there's not many places it would help or there's a suitable alternative I don't have a problem with deleting it. This isn't an area I have worked in at all. ArthurPSmith (talk) 16:46, 30 January 2018 (UTC)
Keep. This will probably become superfluous when the Lexeme data-type comes in and we can actually store etymological information property. But in the meantime this property expresses a different logical relation from said to be the same as (P460) - the surnames are different in their current forms but have branched from the same surname. @Liuxinyu970226: What do you mean by humanization? Deryck Chan (talk) 11:10, 13 February 2018 (UTC)
Withdrawing my keep vote because I trust other discussant's opinions that we already have a better way to store this information. Deryck Chan (talk) 12:50, 13 February 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
It turns out that these are storing members of the same single set of values, which can mean storing the same value twice where a plant species (or even more commonly, a parent taxon like a genus, or a family, such as Orchidaceae (Q25308) ) occurs in both places.
Unfortunately, that was not declared when the second of those properties was proposed.
Not only that, but the eFloras site has many other floras and checklists (listed on its home page), using the same type of ID. In some cases twenty or more of these use the same value (see example, below), and thus we would need twenty or more properties to link to them all in the same manner:
Example URLs for various floras, for a single taxon
It is possible - and would be sensible - to combine these as one property, using the formatter URL http://www.efloras.org/browse.aspx?name_str=$1 (example for same taxon: http://www.efloras.org/browse.aspx?name_str=10638 - note that that includes links to all of the individual flora pages shown in the collapsed section above).
We could either create a new property, migrate values from, and then delete, both of the above properties; or migrate values from one to the other and delete the former and rename the target. I am ambivalent as to which solution is best. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits21:54, 7 February 2018 (UTC)
This is not the forum to complain about deficiencies in the documentation on the eFlora website; contact details for such purposes may be found on that site. The formatter URL I gave above is also a a search by id and results in a single record; helpfully that record has links pointing to the 20+ (in my example) other records that eFlora holds for the taxon. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits22:25, 14 February 2018 (UTC)
Keep: why make it unnecessarily complicated. Also, this approach would make it much more difficult to edit an item. - Brya (talk) 04:17, 10 February 2018 (UTC)
This proposal reduces, rather than increasing, complexity (one property rather than 20+; one value on an item, rather than 20+ identical values). No evidence to support the assertion that it would "make it much more difficult to edit an item" has been offered. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits18:34, 12 February 2018 (UTC)
Also, I found this quote, on the proposal discussion for P1727: "As all the e-flora's use the same number, perhaps they can be handled all together? Not sure how many of them are really interesting (North America, China, Pakistan, Taiwan, any others?)." - Brya 18:19, 16 February 2015 (UTC) . Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits23:31, 12 February 2018 (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.
A while ago, Wikidata:Property_proposal/dialect_of was proposed and quite a few editors were supporting the creation under the condition that "has dialect" (P134 (P134)) is deleted, because "dialect of" should be the correct direction for this relation. The discussion has stalled there so I am proposing P134 for deletion.
Of course, if there is a clear consensus here, "dialect of" should be created first so that the existing information can be migrated. − Pintoch (talk) 10:36, 10 February 2018 (UTC)
Support I agree with the logic, and this also seems in line with common sense about referencing: "A is a dialect of B" is what you'd mostly expect. Charles Matthews (talk) 10:45, 10 February 2018 (UTC)
Delete provided "dialect of" is created first and appropriate jobs are run to transfer the data before deletion. - PKM (talk) 19:22, 11 February 2018 (UTC)
Weak oppose. I agree that "[subject] is a dialect of [object]" is the more useful property, but "[subject] has dialect(s) [object]" is useful for infoboxes about languages too. I weakly prefer to have both, but if the consensus is that there can only be one I would rather have the new "is dialect of" property. Deryck Chan (talk) 11:21, 13 February 2018 (UTC)
Pintoch, please validate the property isn't being used in other projects (using {{ExternalUse}}) and if it is leave a message in Village pump of those projects! Please provide links to the relevant messages.
@ערן: thanks for the reminder! (the skull is kind of scary though!). Although there seems to be a consensus for deletion here, it is still not clear if creation of the reverse property is going to happen as Jura1 has marked the property as not ready. So notifying the Wikipedias might be premature? I don't know. − Pintoch (talk) 08:03, 27 February 2018 (UTC)
It seems Micru just made it up when creating the property. There is a substantial difference between what people agreed on and what was actually created. --- Jura19:13, 10 April 2018 (UTC)
The property was created taking into account the objections raised during the discussion. It was suggested to make the property more generic to include more use cases. Micru (talk) 19:14, 10 April 2018 (UTC)
If you agree with the one person who suggested that, you can revise the proposal and support it. This leaves the other participants in the discussion the possibility to review it and oppose or agree with it. --- Jura19:17, 10 April 2018 (UTC)
@Jura1: Ok, I will take your comments into consideration in future property creations. Do you really want to nominate this property for deletion or did you only want to raise awareness about the proper procedure for property creation? Micru (talk) 20:34, 10 April 2018 (UTC)
I tend to think it's too generic. If you really want to experiment, we can let stand and see what happens. Maybe in a year or so you will want to list it for deletion. --- Jura20:48, 10 April 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
keep but with largely modification, the name "print run" can be by theorical useful for printer cartridges, e.g. I would propose to describe "HP 88A" P4877 (P4877) 1500 pages. --Liuxinyu970226 (talk) 02:44, 1 April 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
This is a highly controversial property and is the subject of much discussion. No consensus was achieved, just one editor making the decision to (a) name it something they decided was going to work and (b) make it live without a consensus being reached. If this is supposed to be used for outreach that connects Wikidata and Wikipedia, then the editors who are doing all of this outreach and work should be consulted before such a big step like this is made. It's not okay.--BrillLyle (talk) 07:43, 4 April 2018 (UTC)
The (tough) decision was made after a discussion with 22(!) participants, maybe one of the largest number of participants in the creation of properties. Sjoerd de Bruin(talk)09:04, 4 April 2018 (UTC)
delete as not yet By counting votes of that proposal, 11 "support"s, 7 "oppose"s and 6 "comment"s makes it only 45% support, thus I'd love to say it's too premature to have this property. --Liuxinyu970226 (talk) 11:10, 4 April 2018 (UTC)
That is not a vote; the closer's job is to weigh the arguments and represent the emerging consensus, not count supports and opposes. That said; your maths is wrong; more than one person made multiple "oppose" !votes (and when I asked BrillLyle to strike one of hers, she did nothing). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits13:41, 4 April 2018 (UTC)
IMO Liuxinyu's count could fairly be reported as 50% support/23% oppose/27% comment. (I chose "comments" rather than "neutral" because comments are not necessarily neutral, or even relevant to the decision at hand). I agree with Andy that reporting "only 45% support" is often going to be interpreted as "55% opposed", which would leave people with the wrong impression. WhatamIdoing (talk) 23:25, 9 April 2018 (UTC)
This property was requested for a specific purpose. It was neutered; it does not offer the usability that is needed. The point of the requested property is that it should provide protection against deletion and as that is not on offer; it follows that I no longer can support the use cases I had. So the question is who did you create if for and why should it be safe to develop a project. Thanks, GerardM (talk) 12:01, 4 April 2018 (UTC)
Proof perfect that you do not understand what the property was intended for. Proof perfect why I will not use it. Thanks, GerardM (talk) 14:14, 4 April 2018 (UTC)
@GerardM: Proof perfect for not understanding "why should", as you did indeed state your reasons for "why should" in the property proposal; a search of the proposal didn't really turn up "how could", which you may wish to explain. Mahir256 (talk) 23:40, 4 April 2018 (UTC)
Keep I really don't understand the arguments against this. If you don't like this property, don't use it; there are clearly some who wanted it from the discussion. ArthurPSmith (talk) 12:26, 4 April 2018 (UTC)
@Mahir256: Thank you for the cleanup (I haven't had to post so many diffs crossing so many projects before.) Responding to an edit summary seems a little awkward, like I'm talking to voices that aren't there ;-) Did you see the Twitter link Multichill linked to? If you want to raise the issue, please do so in the discussion there. --Theredproject (talk) 23:52, 4 April 2018 (UTC)
How does this not constitute a personal attack and harassment? Theredproject has a consistent pattern of abuse and nastiness -- as well as unethical dealings. But he's going to write me up and use the system against me. For all of his so-called contributions. This is unbelievable. For those who support him in doing this, please examine this. Ask yourself why Theredproject is so threatened by me, a lone editor, asking questions, objecting to having my efforts at WM NYC and in this GLAM outreach -- both highly positive and impactful work in fact -- why is he reacting this way? It is not okay. But yeah, go ahead and support this kind of lynch-mob mentality. He will use all my hard work for his own self-serving purposes and it will be supported and allowed. Scumbaggery at work. Be careful. If you make a misstep or question anything related to A+F they will come after you. -- Erika aka BrillLyle (talk) 13:21, 5 April 2018 (UTC)
Keep I agree with ArthurPSmith: I don't understand the drama. If BLT people don't wanna use this property because some obscure reason I'm not able to grasp, and keep insisting on using catalog (P972) instead (is it because they think that one provides a protection against deletion?)... then ... don't use P5008. End of story. strakhov (talk) 13:15, 4 April 2018 (UTC)
Keep yet another bad faith and pointy action by BrillLyle. The property was created to solve a problem with the data modeling of the BLT project and other community activities -- lets try using it. Sadads (talk) 13:33, 4 April 2018 (UTC)
Keep "No consensus was reached". If you see consensus as 100% of the people commenting is in favour of creating the property, then yes there is no consensus, but then there will be no consensus more often. Just 1 person needs to oppose for whatever reason and there won't be any consensus. But that's not how it works. Consensus is reached by weighing opinions and if the outcome is that the arguments in favour of creation are better than the arguments against, than there is consensus. Mbch331 (talk) 16:24, 4 April 2018 (UTC)
Keep I have an immediate use for this property: I am going to be creating items for batches of books that particular batches of maps that I am uploading to Commons are taken from. The only thing linking these books is that some maps from them happen to be in the batch that I am working from. This property is exactly useful for that purpose, meaning that I will now be able to write easy queries and Listeria pages for that set of books, until I am satisfied with them, can untag this batch, and move the property on to the next batch. I don't even start to see why BrillLyle thinks this is objectionable, and frankly find it quite offensive -- whatever dramas she may have of her own -- if she thinks it's for her to shut down somebody else's intended workflow. Jheald (talk) 19:22, 4 April 2018 (UTC)
Update: specifically, see item Q51540075 (Reasonator for list of uses), used so far eg to check all items have a family name (P734) (tinyurl.com/ydasw7va), and that they are all indeed instance of (P31)family name (Q101352) (tinyurl.com/ydaw2cxu). I'm finding it's very handy to have the items tagged, making it so easy to run any new query over them that occurs to me. The next stage is to compare what's there to what I have extracted from VIAF: this now makes it so easy to write queries to extract all the items and all their property values. Jheald (talk) 19:59, 6 April 2018 (UTC)
Keep, I opposed the original proposal because I felt, and still do, that this new property was not necessary to resolve, and didn't fully address, the specific issues that prompted it regarding BLT... but the proposal appears to have taken a life of its own, and at face value now, it seems fine to me for its own purpose. I have to support given Jheald's plans to use it productively, but agree with ArthurPSmith's sentiment 'If you don't like this property, don't use it'. I hope everyone is aware and comfortable with the allowed value of this new list property as WikiProject (Q21025364). @Jheald: mentioned creating a new item "Wikidata focus list" for the value, like catalog (P972) takes value catalogue (Q2352616), but that has not happened. I sympathise with @Liuxinyu970226: questioning the consensus as there were many viewpoints coming from different angles, and a lot to wade through. I'm not sure all the supports (or even the opposes) were entirely aligned with each other. The discussion didn't get into finessing implementation details, hence my slight concern that the current subject value was not as intended? I trust the editor(s) reviewed carefully before acting. Salpynx (talk) 10:50, 5 April 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Premature creation, datatype was changed after some users commented and others still questioned it --- Jura05:57, 19 April 2018 (UTC)
Keep I trust the judgment of the property creator, the arguments given were good enough to create the property.--Micru (talk) 11:42, 19 April 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Delete AFTER the import to the new property, and after we notify the 6 language wikipedias that have templates that use this. ArthurPSmith (talk) 14:05, 19 April 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.P5100 (P5100): (delete | history | links | entity usage | logs)
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.
Hi Micru - I don't know if you followed my comment on that proposal, but everybody voting for it seemed to be thinking of it as a property to describe a scholarly presentation at a conference, and yet nobody provided a case of such as an example using wikidata items. The property now has as an example of a film presented at a film festival, which I believe we usually model with other properties; in any case that seems a very different domain. I'm not at all sure how this is going to be used now; nevertheless I oppose Jura's kneejerk deletionism for properties like this - let's at least give it a few months and see if anybody uses it and how. If it's barely used at the end of this year then yes I would support deletion. ArthurPSmith (talk) 14:14, 19 April 2018 (UTC)
That's correct. In my opinion there is no issue sharing the property as both relate of a work being presented in an event.--Micru (talk) 06:46, 20 April 2018 (UTC)
Ah, ok, I stand corrected. That's fine then if it works for that purpose great. Not sure it will work for the other one anyway (there seemed some confusing about what exactly is presented in those other cases). ArthurPSmith (talk) 12:17, 20 April 2018 (UTC)
Keep The use of this property for films at a film festival seem to be a reasonable interpretation of the property proposer's intentions. Some people present a creative work at an event. The same logical (and human language) relation applies to both scholarly works presented at a conference and films presented at a festival. Unless we explicitly define otherwise, it is reasonable to keep these as one property. Deryck Chan (talk) 14:17, 20 April 2018 (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.
Merge into language of work or name (P407) and rename P407 to "language".
P407 was originally called "language". Later, P407 was renamed to "language of work" and at the same time the proposal for P2439 (P2439) was started to also have a language property for names and terms. Meanwhile, however, P407 is no longer used only for works, but also for names (~35,000 uses) and terms (~70,000 uses). With this perspective, the property P2439 (P2439) (~2100 uses) is obsolete and an unncesseary complication. --Pasleim (talk) 15:15, 9 December 2017 (UTC)
Comment There isn't much benefit in combining language of works with languages of names. P2439 (P2439) was meant to cover this and uses of Property:P407 could be moved there. The main problem with P2439 is its label. It tends to be used for anything and the way the language is associated with an item is even less clear (I think Pasleim did quite a lot of cleaning up these days). We haven't even sorted this out for books yet .. --- Jura15:24, 9 December 2017 (UTC)
Delete This is just redundant and not-well-defined. If we need a new language property (do we?), let's make a new proposal with arguments pro and against. Matěj Suchánek (talk) 16:33, 9 December 2017 (UTC)
@Jura1: Attention please: Matěj Suchánek is voted delete above, so one of your "per" is invalid, would you please pick another user's comment, or just drop that "field value"? --Liuxinyu970226 (talk) 05:05, 10 January 2018 (UTC)
Pasleim, please validate the property isn't being used in other projects (using {{ExternalUse}}) and if it is leave a message in Village pump of those projects! Please provide links to the relevant messages.
in general - please try to mention in the property talk page that modules/templates are using properties so if/when they are getting merged wikidata users can let you know. Thanks, Eran (talk) 22:28, 26 February 2018 (UTC)
@117.136.55.8: You just cited me, but I don't know for what ! Unfortunately, I cannot even ping you correctly to get a reply from you because you were connected only by your IP, unless you are still connected with this IP and you visit this wiki rapidly afer my edit here. Verdy p (talk) 11:25, 3 March 2018 (UTC)
@ערן: The French WP templates don't use anylonger this property, so to my best knowledge this property isn't used anymore on any Wikimedia site. --Pasleim (talk) 17:43, 27 March 2018 (UTC)
Pasleim: thanks for pinging. This was widely used property, so I think it would be best to verify it with wbc_entity_usage table, but here are few other few existing usages that should be updated:
Note: Modules with the name "Wd" won't actually break when the property is gone. Yet it is cleaner to remove it from the modules, of course. Simplest way to do this is to update to the latest version of en:Module:Wd and submodules. Thayts (talk) 07:06, 4 April 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
@Jura Compare with place/Earth (Encyclopædia Britannica Online ID (P1417)), we do not break this down into place and Earth. I think the case is even better for Wolfram Language entity code (P4839) since place/Earth is just a URL snippet while Entity["Country", "Japan"] is the input form as given by the function InputForm. However, while the formatter URL works in the property examples of the property page, it does not work in the item pages such as here. The examples also do not show up well in the property talk page because of the ] bracket and the property is not recognized as an identifier (not sure whether it should be considered as such). -- IvanP (talk) 05:41, 14 February 2018 (UTC)
Datatype seems incorrect, in my opinion. These are all things that still need to be sorted out. Not sure if people read much of the proposal. It's not a property for languages as some assumed. --- Jura05:46, 14 February 2018 (UTC)
Keep I concur with Jura that we (or more specifically @IvanP:) should cease using the property until format concerns are resolved, but I disagree with deleting the property entirely. We've discussed formats for some properties long after they've been created--heck, some properties are so underused that we could start a discussion for one's format with the most minimal of impacts. Mahir256 (talk) 16:44, 14 February 2018 (UTC)
@IvanP: As far as I'm aware, data types can only be changed by deleting the property and re-creating it with the correct data type. (Support deleting and recreating as external-id property.) --Yair rand (talk) 22:06, 14 February 2018 (UTC)
Just to clarify: I do think this should eventually be created. The question is just with what format. And yes, I think we should avoid changing around formats once a property is created. I don't think we should oppose the creation of properties merely because the format isn't sorted out yet. --- Jura09:10, 15 February 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Q21027105 can also be deprecated and deleted, as 'no value' can be used instead (and more correctly) to specify that property values should not have any units. Dhx1 (talk) 14:06, 20 April 2018 (UTC)
Delete no longer needed as P2302 is active for properties. BTW, there seem to be some incorrect uses on items that would need to be fixed in any case: Q3430046#P2046. --- Jura09:24, 19 April 2018 (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.
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 appears to be spam, the site is blacklisted on enWP for spamming. It has no obvious use other than promoting a site that is not usable as a source.--JzG (talk) 18:19, 1 May 2018 (UTC)
Keep Banned on English Wikipedia doesn't mean banned on other WMF sites, even in the case that that is listed on global spam blacklist. The English Wikipedia eventually doesn't allow using [[d:QXXX]], but what happened? Its only result is that many new and brave Wikidata users no longer trust English Wikipedia. --Liuxinyu970226 (talk) 07:34, 6 May 2018 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Delete but the proposal is still valid and the property should be re-created in some months when the datatype will be available. Cdlt, VIGNERON (talk) 12:39, 24 May 2018 (UTC)
Actually we can't fix it by putting it on hold, the property needs to be deleted and not created again until Senses are live - the property data type should be a Sense, but it's currently a Lexeme, which is just wrong. ArthurPSmith (talk) 19:14, 30 May 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
for example Wikidata:Lists/List of trees in Spain is something I would think could be a sitelink for this sort of "dataset", but it's not an import page, it's a list page. And you can't have 2 sitelinks to the same wikimedia project, so what if we want to import that list (if it hasn't already been)? ArthurPSmith (talk) 14:03, 29 May 2018 (UTC)
Keep, it cannot be done with sitelinks, currently there is no way to know what data is being added from which sources, this property allows us to understand this. It will also allow people to collaborate on collating datasets on a subject and importing data from them into Wikidata. --John Cummings (talk) 13:53, 29 May 2018 (UTC)
Keep as per the comments above sitelinks are not a good option for this. The main issue is that you can't have more than one link to Wikidata, but also there is no way to include any explanation with a sitelink to explain why it is there. Using a property automatically gives us a place to have the relevant info that editors will need to find when coming across this 'dataset import page' link for the first time. NavinoEvans (talk) 14:44, 29 May 2018 (UTC)
It was recommended to me to ignore your explanations. Possibly your confusing way of referring to your own reasoning isn't really helpful. Maybe it's your way to avoid addressing the question at hand. --- Jura15:48, 3 June 2018 (UTC)
Keep Jura1, please drop your titan arguments to throttle supporters, you should better make conflictions about the usage, rather than "hey, this rabbit should be killed! / No, that shouldn't!". --Liuxinyu970226 (talk) 04:29, 11 June 2018 (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.
Unused property, with no example. It is completely unclear to me as a chemist how this could ever be used. "Quantity" data type, which sounds like you're meant to count how many spectral lines the compound can emit, to which the answer is almost always "near-infinite", and depends whether you include vibrational, rotational, and translational states.--99of9 (talk) 01:20, 30 May 2018 (UTC)
Delete and the property proposal didn't really receive any discussion either; looks like it was just auto-created after the Quantity datatype became available without any thought as to how it would be used. I can imagine the intent was to allow one to add (one at a time) each spectral line as a particular wavelength of absorption or emission, that would make some sense. However, I think a better solution for this is to use the tabular data format so you could list a collection of lines at once. Given this has never been used I don't think we need to keep it around; a new proposal for this would hopefully be more fully fleshed out next time. ArthurPSmith (talk) 13:15, 30 May 2018 (UTC)
Ok, that makes more sense. But it could get very long, so a table, an actual spectrum, or a link to a spectral database is probably preferable. --99of9 (talk) 01:07, 15 June 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
I'm sorry for being rude but the property was created during an ongoing discussion at Wikidata:Property_proposal/SPARQL_endpoint to modify the scope of the proposed property. The property was never marked as ready to be created. If we reach a consensus, fine but pushing a decision this way is not ok. --JakobVoss (talk) 13:20, 13 June 2018 (UTC)
Comment (EC) Me as well. The property can get deleted now and undeleted in the case that the proposal discussion part 2 is in favor of it the way it was created. --Marsupium (talk) 15:13, 13 June 2018 (UTC)
Keep. Wikimedia projects work on a combination of majority-vote and consensus-building. Unanimity is never a requirement for any decision. Furthermore, from my reading of the property proposal discussion, every editor agreed that a new property that encodes a URL is required; the only disagreement is whether the scope should be SPARQL endpoints only or API endpoints in general. Therefore I Strong oppose deletion and I think we should continue that discussion at Wikidata:Property_proposal/SPARQL_endpoint. Deryck Chan (talk) 15:54, 13 June 2018 (UTC)
Keep Broadening scope is still possible, either by consensus at its talk page, or by a new property having SPARQL endpoint URL (P5305) as subproperty. IMHO there was clear consensus, first marking as ready is not necessary in this procedure. Perhaps indeed it would have been better that discussion about broadening be finished before creation, apologies for that. But I don't think (temporary) deletion yields benefits. Lymantria (talk) 17:03, 13 June 2018 (UTC)
There are arguments against having two properties, these were discussed before property creation. If the discussion leads to a more clear picture I'm fine being outvoted. To allow open discussion without deletion I temporarily renamed the property to "SPARQL/API endpoint (experimental)" until arguments have been exchanged. Is this a valid way to proceed? -- JakobVoss (talk) 21:14, 13 June 2018 (UTC)
Weak supportKeep, true the creation was a mistake, it was too early but I feel that the deletion would be a mistake too (we have more importnt and constructive things to do than deleting and recreating again the same properties). Cdlt, VIGNERON (talk) 14:30, 14 June 2018 (UTC)
It's true there wasn't unanimous support for the proposal, but this isn't a requirement. Personally, I think the suggested alternative was already addressed in the proposal itself. Apparently it wasn't exactly successful in building a consistent list of such endpoints. --- Jura04:21, 15 June 2018 (UTC)
The point is not whether the creation was formally right or wrong but which data model best fulfills our needs (while no agreement on "our needs" exists). I tried to further clarify my objection at Wikidata:Property proposal/SPARQL endpoint#Scope_of_this_property, in the end the question is which use case should be weighted more: query SPARQL endpoints (specific) or query API endpoints with all protocols, including SPARQL (generic). Personally I prefer the second but it's not important enough to further discuss here, the Wikidata data model is inconsistent anway. So Keep this property if you like, but please don't create more protocol-specific endpoint properties -- JakobVoss (talk) 20:13, 15 June 2018 (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.
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 is used and labelled inconsistently. The meaning of the property was changed a while after it was created, but not all of the labels were updated to reflect that decision so that some labels mean "number of platforms", which can mean several different things depending on the region and language as well as context, and some labels mean "number of platform tracks". As a result, an insubstantial number of values could be or are incorrect, since they describe the number of platforms counted in a different way. Several different replacement properties could be taken from this property proposal discussion (properties were not created). Jc86035 (talk) 12:50, 17 May 2017 (UTC)
As an example, Greenford station (Q800841) has one island platform with a bay platform inset. Quoting Thryduulf: "The outside faces have one platform number each (1 / 3) and are used exclusively by London Underground. The bay platform has a platform on both sides of the train but one number (2), currently the doors only open on the north side of the train (due to rolling stock limitations, not station infrastructure limitations, so future trains may be able to use both sides). It therefore has 1 (island), 2 (island + bay), 3 (platform numbers in use; independently signallable platforms; tracks adjacent to platforms) or 4 (platforms adjacent to tracks) platforms." The British English label was different to the English label for more than a year, so if this property were added for it, it could have had any of the aforementioned values depending on the user interface language of the editor and how they counted platforms. Jc86035 (talk) 12:59, 17 May 2017 (UTC)
@Multichill: The problem is that because the data is polluted and half the labels are still wrong, we don't really know if the values are correct. I suppose all the values could be gone through (this would have to be done manually for all of them) and the labels redone. Jc86035 (talk) 12:34, 18 May 2017 (UTC)
I also have to say Keep:
I don't think it's clear what is intended to happen if we were to decide on "delete". Some people are talking about how to store the data (whether to keep this property or use different ones), other people are talking about whether to keep the existing data for this property, and I wouldn't be surprised if someone started talking about whether we want to store this data at all.
Unless we decide we do not want to store this data at all, the data will need checking at some point. If we delete what we have and start again, it will need checking as it's re-added, therefore I don't think deleting it is very productive. We should focus instead on finding ways to verify what we have and what people will add in the future.
It shouldn't be that hard to check the labels, identify which ones need fixing and then ping speakers of those languages.
As for the data, I'm only familiar with Germany and the UK (which happen to account for over half of the uses of this property). Information about German stations is available as open data and the National Rail site has maps of UK stations so the data for those two shouldn't be difficult to verify (although maybe a bit tedious if it can't be automated). Other countries may have similar resources available.
I think you are probably overestimating the scale of the problem. I would expect the majority of stations to be small and straightforward stations which produce the same number whether you're counting the right thing or not (e.g. single track plus single platform or two tracks plus two side platforms). In the UK, smaller stations with islands are likely to accidentally produce the right number too. In Germany, it's normal to talk about tracks rather than platforms, so those are also likely to be correct.
@Liuxinyu970226: Sorry, I got halfway through replying before being distracted by other things. I would propose the following:
Wait for this discussion to be closed (if the decision is to delete it, there's no point trying to fix it).
Check and fix the labels and descriptions on the property. This could be done by creating a new section on the property talk page and pinging speakers of those languages. If there are any which can't be verified after a period of time, remove those until someone who speaks the language can check/fix them.
Check the existing statements with references to make sure those are correct (there aren't many, from what I remember).
Find sources we can use to check the rest of the statements. I already mentioned knowing of sources for the UK and Germany. Italy is the next biggest one.
Check the statements against the sources and add references to the ones which have been verified. How we check the data depends on the sources, some can be automated, others will have to be done by hand.
Decide what to do with the statements which can't be verified.
Not really 7th, it can be done at any point: Discuss somewhere else (on Wikidata:WikiProject Railways?) other ways of counting and how we should model those.
Since my last comment, I've checked most of the UK ones. Over 1500 are correct and about 100 need further investigation for a variety of reasons (not all of them are wrong). I'm not sure how to add the references though, I think it might need a bot. - Nikki (talk) 10:03, 10 July 2017 (UTC)
@Liuxinyu970226: Some cases are more complicated and will need qualifiers. I didn't say that 22 is the right number, it's one of the ones which needs more investigation. It seems that 19 and 24 are correct for the total number (at different times), 19, 20 and 22 are correct for the number in use (at different times) and the sitelink for kawiki was on the wrong item. - Nikki (talk) 10:41, 15 July 2017 (UTC)
@Nikki: Unfortunatelly your solutions haven't explain what to do for Spanish solution (Q1342434), that's my key concern. In Spanish solution (Q1342434) stations, the "physical" total numbers of platforms are always mismatching tracks and faces, yeah, numbers of all 3 things are 2-2 different. So. e.g. which should be the "correct" value of Changhua TRA station (Q5071979)? 5? But near all of TRA trains do not allow opening doors on two sides in the meantime, so one of "5" is unavailable. 3? that's number of tracks, and one of "3" is available for two lines. 4? So articles in all 3 languages are saying wrong values. --Liuxinyu970226 (talk) 08:35, 31 July 2017 (UTC)
@Multichill: Would a solution like « delete after data fixing » would do the trick ? A kind of deprecation. This lacks ous current workflow. author TomT0m / talk page11:16, 20 May 2017 (UTC)
@Liuxinyu970226: As Thryduulf stated in the prior discussion: some stations (UK, Taiwan, etc.) have independently signallable A/B platforms on the same face, stations in different parts of the world number platforms differently, and so on. I think several more items/properties might need to be created for those (has part → platform number?), but for most stations has part(s) (P527) should suffice. Jc86035 (talk) 05:13, 20 May 2017 (UTC)
Keep, I am not a fan of "use this very generic property with this obscure item/qualifier combo". Useful property. Sebari– aka Srittau (talk) 15:27, 23 May 2017 (UTC)
@Srittau: I'd personally prefer to have separate properties for the seven or so ways to count platforms, but the problem remains that this property is not defined correctly in all languages and the data is inconsistent. If the property is to be kept, the data should ideally be reviewed (or wiped and re-imported) for each rail system where the property is in use. Jc86035 (talk) 09:46, 24 May 2017 (UTC)
|月台数目=（車站側式月臺的數目，此參數可選）//physically numbers of Q2735706+Q2725290, but document says only Q2735706
|侧式站台=（車站島式月臺的數目，此參數可選）//numbers of Q2735706, but document says Q2725290, and even in case of Q2735706 this is also including Q877472-like cases
|岛式站台=（車站月臺面的數目，此參數可選）//numbers of Q2725290, but document says "platform faces", and even in case of Q2725290 this is also including Q877472-like cases
|站台面=（車站月台的數目，此參數可選）//numbers of "platform faces" (where's the item of this concept?), but document says Q2735706+Q2725290
Also, this property should NOT be used at stations of Singapore and Malaysia (at least until the fully solutions of platform-related property usage is documented) because of the significant huge number of Spanish solution (Q1342434) usage. --Liuxinyu970226 (talk) 01:41, 30 June 2017 (UTC)
Delete or deprecate. It's not defined which of the many ways of counting platforms this is intended to represent, nor which of these ways any current use is using. This means we can't correct the data as we don't even know what is correct, and even if we do decide on a definition there will be no way of verifying whether uses are correct to it without manually looking at plans of the given station - which has no benefit over entering data afresh. Thryduulf (talk) 21:15, 7 July 2017 (UTC)
Keep Surely there is a confusion between number of platform tracks and number of platforms (even translations of criterion used (P1013) are inconsistent), but in my opinion the solution is to create new number of platforms property and clarify existing data. Both concepts are widely used in transport-related infoboxes in various languages.--Jklamo (talk) 14:49, 12 July 2017 (UTC)
Oppose Per above, this property is already existing, you might want to request another property for the number of physical platforms. --Liuxinyu970226 (talk) 09:01, 2 February 2017 (UTC)
@Liuxinyu970226, Pasleim: Updated the proposal to be for number of platform faces; Property talk:P1103 should be updated because it still refers to "number of platforms".did not realize data was taken from en-gb labels Jc86035 (talk) 08:14, 4 February 2017 (UTC)Jc86035 (talk) 14:54, 2 February 2017 (UTC)
So I changed to Support, thx for patches of properties. --Liuxinyu970226 (talk) 13:30, 3 February 2017 (UTC)
@Jc86035: However, I'm afraid that I already typed the values of "站台面" as P1103 value, so am I wrong now? Should I use "站台数目" instead now? --Liuxinyu970226 (talk) 13:51, 3 February 2017 (UTC)
(note that huwiki 10 is because of my value changing) But if following the newest meaning of P1103 (number of tracks served by a platform at a railway station) it really should be 18 psst. should be 22 as 18 (for CR(H?)) (should not be 20 because 2 tracks of this station are headshunt (Q784358)) + 4 (for Beijing Subway). --Liuxinyu970226 (talk) 02:36, 14 July 2017 (UTC)
Delete, per Liuxinyu970226, platform counting styles can always be different between countries, so this property can't reflect all countries. --111.30.229.6409:00, 29 August 2017 (UTC)
I was canvased by Liuxinyu970226 to change my opinion to delete. The current label of the property is "number of platform tracks" with description "number of tracks served by a platform at a railway station". What's difficult about this? Take the number of tracks going through a train station (for example 8 for Haarlem railway station (Q800863)) and deduct the tracks that don't have a platform (track 2 and 7 for Haarlem) and you get the result (6 for Haarlem). So in some countries and languages people didn't stick to this definition. Go mass remove the property there, but don't destroy the work for the people who did do it properly. Multichill (talk) 09:11, 23 September 2017 (UTC)
The original English label is "number of platforms". The label was then changed without notifying translators to update the other labels. If this property is kept, we have to delete all statements added after the English redefinition and stick to the original proposal --Pasleim (talk) 10:05, 23 September 2017 (UTC)
Indeed, and @Multichill: even we can only consider tracks and ignore any kinds of "physical" platforms, please be aware that most stations in rural areas of Southeast Asian countries don't have any possible "platforms", on the other hand, a random abandoned station is likely having no tracks anymore? So in both cases are you sure 0 is suitable? NO! Stations without physical platforms are still stations (at least still providing board and alight services), and stations with no tracks are still stations! --Liuxinyu970226 (talk) 04:22, 22 October 2017 (UTC)
Keep. We can always argue about the definition of "a platform" or "a platform track" and there will be borderline cases whatever criterion we go with. Use qualifier criterion used (P1013) or sources if fine distinctions need to be made. Deryck Chan (talk) 17:01, 8 November 2017 (UTC)
The vast majority of railway stations around the world have one track per platform. The definition of a "platform" also varies from station to station (e.g. most island platforms count as 2 platforms but there are exceptions), so we ought to allow some ambiguity in the way we record them on Wikidata. Wikimedia projects generally collect verifiable information from other sources and disambiguate as required, not impose our ontology onto the world's railway stations and force disambiguation upon information sourced from external sources. Deryck Chan (talk) 11:19, 13 February 2018 (UTC)
Comment This property has some 12000 uses. Some refer to platforms others to tracks. Some count platforms, but mean tracks. I don't quite see how this could be sorted out on the existing property in a reasonable way. Using a new way for each might work out. --- Jura08:47, 11 November 2017 (UTC)
Delete Given that the existing data can't be trusted to have a consistent meaning because of the name change. It's unfortunate but I don't think there's a way to transfer the existing data over in a way that won't leave a lot of errors. ChristianKl ❪✉❫ 13:14, 23 December 2017 (UTC)
Keep, describe with precision and correct errors. I support reasons describes by @Multichill:. There are a lots of properties with very poor use and meaning description in their talk pages. Usually, the english name is the only "clue" to understand what had in mind the creator when done; in addition, a bad translation (interpretation) of labels opens a missunderstanding that must be correct. However, the destruction of the present situation without write down a new precise "use of property handbook" of the new solution will (re)produce -in some time- a similar problem. Regarding solution « has part / has part of the type + number », I disagree because this generic properties increase the difficulty for "getting users" of WD, via query, via API or via WP module to build an infobox, for instance. Is easier to have an specific data for an specific concept, and leave these solutions for marginal situations not foreseen in the data model. Now, I'm working in create a "WD full powered infobox for stations" and the data collection for this area of knowledge is not the best we have. So, keep clear another conceptual inconsistences are prioritari to me than destroy the few content we have now. Thanks.Amadalvarez (talk) 06:20, 17 February 2018 (UTC)
Then this property should have Wikidata item of this property (P1629) which value? If there's no criteria way that to be documented then @amadalvarez: I suggest you to change your keep to delete because the Dutch translation means "number of railway tracks" which probably has way to mean "of a railway line", the Hungarian usage (currently only one usage) should be checked either @tgr, tacsipacsi:. --121.227.37.1023:25, 1 March 2018 (UTC)
Let my ask, what's the alternative property when we delete this one ?. I just say that, before delete, we all together must agree with a non ambigous definition and then, or create a new one property or redefine this one and clear all content that doesn't match with the new definition. My concern is that some people think that deletion must solve the problem (it remind me a President that wanted to chop all forest to avoid the forest fires). I'm not defending present situation, I just want to avoid repeat the problem when someone else try to create a property to "track lines" or "point to get the train" or "platform that can be show at display station" or... or.... Thanks, Amadalvarez (talk) 12:45, 2 March 2018 (UTC)
Delete The current property is ambiguous within and between languages and inconsistently used to the point where it is not even possible to say what the correct value for any station more complicated than a single track adjacent to a single platform with a single signalling berth, let alone whether any particular value matches that. The diagram illustrates just some of the problems, not showing bay platforms for example. One aspect of the problem is that there are no standard, unambiguous terms for most of the different types of platform and almost no sources specify how the platforms are being counted. It is not even standard between stations in the UK - Bristol Temple Meads uses the red numbering system, Birmingham New Street uses the blue system, Stratford isn't even consistent within itself (3/3A, 4A/4B and 11/11A are all different layouts). The way forward is to hammer out what exactly we want to count and then figure out how to describe that, then figure out how to represent that in Wikidata, then figure out how to translate the data into that format. The current property is not useful for any of that. Thryduulf (talk) 20:35, 3 May 2018 (UTC)
For the record, since it's been more than a year since I nominated this for deletion, if the property is deleted I would prefer to convert everything to has part(s) (P527) statements indicating quantity (P1114) or series ordinal (P1545) (although another property might need to be created for platform numbers like 2A). I think requiring it be done this way is a better solution, since it's clear (by this point, I hope) that for some reason there is no standard way to count platforms. Jc86035 (talk) 16:35, 12 July 2018 (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.
Comment I don't think it was created by error either. It's just not used. I came across it when checking completeness of constraints on properties. --- Jura09:21, 19 April 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Keep The formatter URL no longer working as a result of the site’s closure does not mean it is no longer useful; there are discussions about Curlie ID (P998) around the time DMOZ shut down and we still have that property today. Mahir256 (talk) 14:33, 10 April 2018 (UTC)
Comment I deprecated the formatter url, but it seems that this property hasn't really been put to use Delete --- Jura19:30, 10 April 2018 (UTC)
Should we really delete a property because so far it hasn't been used much? Because the simple answer here would be to simply use it more. The point here is moot however since the database is down and we don't know the IDs anymore. NMaia (talk) 22:56, 21 April 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
I think you should be aware of the lengthy discussion about the conversion from string datatype to external-id. This one would be in the group we didn't convert. It's possible that some slipped through. Some users think a twitter hashtag should be an external id. If you want to present arguments when discussing properties, you really shouldn't be trying to assess consensus and closing the discussion all in the same post. This is disruptive and unproductive to the process as such. --- Jura10:36, 4 May 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
I believe nobody commented on this nomination because none of the links was provided to back up the deletion. Jura, Could you provide a link to the discussion where it was decided that wiki links should be string-datatype. Alexei Kopylov (talk) 20:49, 8 May 2018 (UTC)
@Jura1: On the previous discussion you said "I think the datatype question needs to be resolved first.", can you please explain what is the "datatype question"? You also said: "you really shouldn't be trying to assess consensus and closing the discussion all in the same post", here I disagree because although you also belong to the group of property creators you seem to ignore the situation that to do what you propose takes too much energy and effort that might not be available. It definitely can be done in special circumstances (I have done it myself in the past) but definitely not for all property proposals, and also not for property proposals that had low participation as this one. Do you agree with that? --Micru (talk) 10:14, 20 May 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Delete The site has been inactive for over a year, I actually checked this once in a while. Currently it just adds noise and helps no-one. DGtal (talk) 06:00, 22 April 2018 (UTC)
Comment the property seems to have a reasonable number of uses (500). Was it useful when it existed? --- Jura06:04, 22 April 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
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.
Yet another disruptive deletion nomination. The proposal that passed was for an external-ID datatype, as clearly discussed on the proposal page. Therefore: Speedy keep. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits18:17, 22 June 2018 (UTC)
Did you notified the four voters about the your applied datatype change? I can't see this at the proposal page. --Succu (talk) 21:39, 23 June 2018 (UTC)
Keep. It's an identifier, it's external => external identifier is the right datatype. It does indeed have datatype "External identifier", so all is well, and no action or modification is needed. Jheald (talk) 15:55, 23 June 2018 (UTC)
Actually, it isn't. At least that was the outcome of the discussion when converting from string to external ids. So if these values aren't stable, it should either be string or url, but not external-id. --- Jura08:35, 24 June 2018 (UTC)
It's not a position that survives contact with reality. This is an identifier, and its external. It's plainly more like the properties below the fold than those above it. It's useful to group it with the things it is link, and to de-clutter as much as we can the more general properties. So long as it is reasonably stable that is enough. Identifiers get merged or revised all the time. Some issuers will redirect the old values, some aren't so careful. Working recently on titles from the BHL (project page), I recently found 2276 titles with values stated at the BHL for Library of Congress Control Number (LCCN) (bibliographic) (P1144) which are plainly well-formed, yet are unrecognised by the Library of Congress tinyurl.com/ycmnhob6. It would appear that these are old values that have since been retired, that are not redirected by the OPAC. Yet would we say that P1144 is not an external identifier? No, because that would be silly. Similarly, many many other external IDs we currently accept may not quite be 100% stable. Does that mean we're going to put them all back above the fold, and (in some cases) take away their linked-data fork? No, we are not. So my view is: whatever might or might not have said when external IDs were first being segregated as a separate group, that is no longer where we are now at, and the balance of advantage is to go with what is now current practice -- if it's an ID, and it's external, make it an external ID. Jheald (talk) 10:11, 24 June 2018 (UTC)
Keep. I agree that the deletion nomination is somehow disruptive, as the datatype has been debated during the proposal. Thierry Caro (talk) 05:33, 24 June 2018 (UTC)
Comment the initial supporters of the url datatype didn't comment on the change of datatype (Wikidata:Property proposal/Amphibian Species of World ID). It seems the creation process went fine. That said, this doesn't necessarily mean the datatype is the correct one. "Anura/Leptodactylidae/Leiuperinae/Pseudopaludicola/Pseudopaludicola-restinga" looks more like an url path than an actual identifier. --- Jura05:47, 24 June 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
This property was proposed at Wikidata:Property proposal/landmass, where it went rather unnoticed, with only two !votes before it was created. It subsequently changed from 'landmass' to 'island of location' (I'm not sure why), and around 8,000 values were subsequently moved over to this from located in/on physical feature (P706), location (P276) and part of (P361) (which is when I noticed it, as some of the changes appeared on my watchlist).
Comment. I'd rather delete located in/on physical feature (P706), which matches with no simple concept in human daily life. Which island a thing is on is understandable. Which terrain feature it belongs to, well, I am not that sure. So let's move what should be back to location (P276) and have the new specific properties populated. The older one was created a long time ago when we were OK with having unclear declarations under catch-all umbrellas. It is now a source of constraint violations and uncompleteness. Thierry Caro (talk) 00:48, 9 May 2018 (UTC)
Deletelocated in/on physical feature (P706) is a more general property that can be used regardless if the object stand on an island, a peninsula, a hill, a mountain, a plain or whatever. The datamodel used on Wikidata today is unconsidered and uncoordinated. There are too many properties thoughtlessly created. Fewer and more general properties and better use of qualifires is the only way out of this swamp. /ℇsquilo12:15, 9 May 2018 (UTC)
Keep I'm also not sure why it changed from "landmass" to "island of location", I assume this was to distinguish from continent (P30). However, I believe those are really quite different concepts - a "continent" generally includes many islands in addition to the main land area (for example Long Island, Vancouver Island, etc. are surely all part of North America), and several "continents" may be located on one landmass (Europe and Asia most notably). I think this is definitely a useful property to have; it's sort of a complement to drainage basin (P4614) for example. ArthurPSmith (talk) 13:20, 9 May 2018 (UTC)
@ArthurPSmith: 'Watershed' is quite different, as you wouldn't normally include that in a string describing the location of somewhere (it's more likely to be a separate line in an infobox). Agree that this and 'continent' are different things, though. In a string of "Located on <X>, location, located in administrative area, country", I'm worried that we'll have to check a huge number of X's, which will vary between topics, rather than just a single one as we currently do - and that makes things unnecessarily complex. Thanks. Mike Peel (talk) 13:39, 9 May 2018 (UTC)
Delete One can not have different properties for an item of same forekomst av (P31) depending on the location is on an island or not. This will end up having Properties like located on a mountain, a peninsula, desert, sump and so on. Pmt (diskusjon) 14:59, 9 May 2018 (UTC)
Deletelocated in/on physical feature (P706) did work well for most instances I have seen. I always thought of it's target as quite simply a "geographic area" and as such could be almost any area, land or sea, forest, island, settled area etc. I suspect Thierry simply misunderstood it.--Hjart (talk) 10:22, 23 May 2018 (UTC)
The new property is a subproperty of located in/on physical feature (P706). So they may not use the same location property but they both use the same property tree. On top of that, and as a sidenote, St. Peter's Basilica (Q12512) may have an P5130 (P5130) value if one really wants this to happen – Afro-Eurasia (Q27527) is an uncertain candidate – but nobody should normally want to document this. So there is no decisive structural difference in the way we deal with the two churches, actually. And eventually, would there be one, would it be that scandalous? That Notre-Dame de Paris (Q2981) is on a small island may make a difference in its geography and history and that is precisely what the new property helps people consider and check. Thierry Caro (talk) 23:00, 20 May 2018 (UTC)
@Thierry Caro: So for St. Peter's Basilica (Q12512) I can use located in/on physical feature (P706)Vatican Hill (Q1053000) since the Property {{P|hill of Location}} do not excist and can not be for St. Peters Church untill it is created. Having an property for an man made geographical item located on an island must for the sake of good order also inflict that a man made geographical item located on a hill also must have its own property, not to say if an item is located on a mountain it really must have its own property helping people consider and check.
And further will be needed... Untill those propeties equal and to the same Level as P5130 (P5130) are settled I propose that P5130 (P5130) are deleted, and a clear structure of how man made geographical objects location should be described by properties in air, land, sea and space. Breg Pmt (talk) 00:56, 21 May 2018 (UTC)
Kindly observe that for Tórshavn (Q10704) the P5130 (P5130) is created by User:Thierry Caro who originaly proposed the property. Adding a new property to an item during the discussion of delation of the said property do not justify the need of the property. In addition| {P|706}} is removed. @ArthurPSmith:. Of the 8901 statements, how many is created by the same user, and how many is created by Quick statements and how many located in/on physical feature (P706) have been removed at the same time? Pmt (talk) 18:21, 13 June 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
P1962 (P1962) and sponsor (P859) are the same relationship, originally proposed for different fields (P1962 for arts, P859 for sports). However, neither property remains limited to the occupations that they were proposed for. P859 even includes research project (Q1298668) as part of its domain. I think these two properties should be merged.--Deryck Chan (talk) 15:46, 28 June 2018 (UTC)
Support merging these two. There is no need to limit use to any specific set of fields; any item for which this kind of relationship exists should be able to use it. Josh Baumgartner (talk) 17:42, 29 June 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The property P5310 was accidentally created anew after a period of not using the property P4237. The simplest would be to merge the two properties to the newer property P5310, which has already been used extensively.--Susanna Ånäs (Susannaanas) (talk) 10:11, 8 July 2018 (UTC)
Delete yes, looks like a duplicate and P4237 is unused (well it had a few uses but those seem to have been switched to 5310 already?) Thanks for noticing this problem. ArthurPSmith (talk) 13:43, 9 July 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Not quite like. P5190 was incorrectly defined and created with the wrong datatype. Apparently P5137 can be used in a couple of weeks. --- Jura06:34, 29 May 2018 (UTC)
@Jura1: According to Léa the Senses will be available in at least 3 months. I think it is a long time to wait with this property created and not be able to use it. For that reason Delete --Micru (talk) 06:51, 29 May 2018 (UTC)
On hold. Judging from how long these deletion discussions often take, we may as well keep this property in limbo until Senses are released and then start using it. Deryck Chan (talk) 11:45, 11 June 2018 (UTC)
And now senses are scheduled to be available in 1 month (October 20 2018) and people are already using this property in preparation by adding values on lexemes directly (to be moved to senses when available) - I think this deletion discussion should just be closed! ArthurPSmith (talk) 12:04, 21 September 2018 (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.
Comment Similarly as the nominated property P4570 (P4570), the proposed property would also be useful for structural items (those which are really structural items, i.e. used in large number by other items). I don’t think the proposed one’s scope should be limited to properties. —MisterSynergy (talk) 22:49, 1 August 2018 (UTC)
The current property is not restricted to structural items, but we could limit the new property to structural items and properties if you think that it is a valid scope.--Micru (talk) 07:11, 2 August 2018 (UTC)
Conditional support On the condition that the new property proposal passes and we migrate all existing uses of this property to the new property. Deryck Chan (talk) 10:29, 2 August 2018 (UTC)
There is no need for a new proposal in the case of datatype changes. If this PfD passes, then the steps outlined above will be implemented.--Micru (talk) 11:35, 2 August 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Per Wikidata:Project chat#Property constraints – music releases, instance of (P31) → single (Q134556) and instance of (P31) → song (Q7366) should not be used on the same item. This means that singles should be treated like albums/EPs, which means that they can use tracklist (P658); so the A-side(s) and B-side(s) should be inferred from or indicated on the single's tracklist (possibly with object has role (P3831)), rather than on the items for the songs. (If it should be indicated on the song items, then that could be done with subject has role (P2868) as a qualifier on a statement with part of (P361) and the single's item.) While structural necessity isn't a strict requirement for the existence of a property, singles have been released with multiple A-sides and with different B-sides for different releases, which would be hard/impossible to represent using just P1432 (P1432) on the item for the mutual A-side.
If there is a consensus to delete, the property should be deprecated and then deleted after there are no uses left. This would require the creation of about 344 items (the number of uses), since most singles currently have one item for both the single and the A-side. An example with separated items for single and song is Eastside (Q55975144)/Eastside (Q55977453) (I created both and I'm not aware of any other examples). —Jc86035 (talk) 12:30, 8 August 2018 (UTC)
KeepB-sides charted separately from their respective A-sides before 1969. See The Beatles' #1 singles for one obvious example of this. - Bossanoven (talk) 11:49, 19 August 2018 (UTC)
@Bossanoven: I think that's irrelevant. This deletion nomination is about how B-sides are shown to relate to their A-sides, and the property's deletion would not negatively affect chart data.
If the single charted (as opposed to the songs) then the chart data can go on the single's item, and if the songs charted separately (as they do now on most charts) then the chart data can go on the songs' items. Usually charts are consistent about this, as far as I'm aware; so other than the issue of singles almost always being conflated with songs in the current data structure (i.e. there being only one item for both the song and the single), there shouldn't be any major problems with this. Jc86035 (talk) 16:59, 21 August 2018 (UTC)
@Jc86035: Wouldn't it remove confusion in the reader's mind to see that a famous A-side charted separately from its famous B-side, and to see this through the B-side property? - Bossanoven (talk) 17:48, 21 August 2018 (UTC)
@Bossanoven: Is Wikidata even meant to be read? I guess its primary purpose is to be a database. If the data exists in the tracklist stored on the single's item then it doesn't necessarily need to be added anywhere else.
Why (and how) would you indicate chart positions through the B-side property? I don't think it would be feasible or technically possible, given the limitations of qualifiers, although maybe I'm taking you too literally. In any case, if the property's purpose is cosmetic rather than functional then it doesn't really need to exist. Jc86035 (talk) 18:09, 21 August 2018 (UTC)
Good discussion, to keep it separated is a good idea! However Wikipedia often mixes song and single, see Hey Jude (Q607742). So is the Wikipedia article going to linked to the song or single. I would suggest to connect to the song, as they are the more important entity. Germartin1 (talk) 15:18, 3 September 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Change data type to string. According to this RFC, this property can't be used correctly in it.voy as they want to show the email with a link to mailto: URI and you can't do [mailto:EMAILADDRESS EMAILADDRESS] right now. —Micru (talk) 18:37, 26 December 2018 (UTC)
Oppose - We shouldn't change the datatype here because 1 re-user (it.voy) can't handle the default output. In this case it.voy should adapt their module:wikidata so it does render the output they want. For some projects other properties may be hard to handle because of their current datatype if they use the data as outputted by default. If the data output doesn't suit you, you need to make a script/module (or ask for help with a script/module) so it renders the way you want. Mbch331 (talk) 14:39, 27 December 2018 (UTC)
Oppose - The property is used in many wikis. To change this means a comparatively high effort. It is very simple to remove mailto: from the string. --RolandUnger (talk) 08:54, 6 January 2019 (UTC)
Support I support changing the datatype, but we should likely first create a new one, copy over the values and then slowly deprecate the old one.
It will be easier to enter data when the user doesn't have to write mailto: in front of every email address and making it easier to enter data is valuable. ChristianKl ❪✉❫ 10:11, 6 January 2019 (UTC)
Oppose - It is not a big deal to make [mailto:email email]. I don't know which tool are you retrieving the email from Wikidata, in my following example, I use Módule:WikidataIB:
Delete - no idea what Jura's referring to; it looks like series ordinal (P1545) is already being used on the months where they are described as subclasses so the data is there. I really don't think it is helpful to have a property like this that is entirely wikidata-internal and applies to only 12 items, there have to be other ways to do it. I would question the creation process on this one. ArthurPSmith (talk) 14:45, 4 August 2016 (UTC)
Keep Given that there are probably many queries where it makes sense to look at this property and it increases the speed of those queries, I'm okay with keeping the property. ChristianKl (talk) 09:29, 5 June 2017 (UTC)
Comment @Gstupp: what do you think, as property proposer? It does seem to me like this is a bit redundant. ArthurPSmith (talk) 19:07, 8 November 2017 (UTC)
Question @Oravrattas: Can you fix the URL format string so that the IDs of former members of parliament will also lead to a valid link on the website? Deryck Chan (talk) 10:31, 23 January 2018 (UTC)
Notified participants of WikiProject Names
WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. --Succu (talk) 21:57, 7 February 2018 (UTC)
Keep. Both are pubished as books too. --Succu (talk) 22:01, 7 February 2018 (UTC) BTW: Why should we link to a search result? --Succu (talk) 22:11, 7 February 2018 (UTC)
Support I agree with the logic, and this also seems in line with common sense about referencing: "A is a dialect of B" is what you'd mostly expect. Charles Matthews (talk) 10:45, 10 February 2018 (UTC)
Weak oppose. I agree that "[subject] is a dialect of [object]" is the more useful property, but "[subject] has dialect(s) [object]" is useful for infoboxes about languages too. I weakly prefer to have both, but if the consensus is that there can only be one I would rather have the new "is dialect of" property. Deryck Chan (talk) 11:21, 13 February 2018 (UTC)
Neutral. --Liuxinyu970226 (talk) 00:58, 6 April 2018 (UTC)
Done deleted by Mahir256 --Pasleim (talk) 19:23, 3 May 2018 (UTC)
On hold until Senses are live and we can fix this. Deryck Chan (talk) 15:02, 29 May 2018 (UTC)
Strong oppose deletion and I think we should continue that discussion at Wikidata:Property_proposal/SPARQL_endpoint. Deryck Chan (talk) 15:54, 13 June 2018 (UTC)
Weak support 
instead. This discriminates specified parts (parts for which we have actual items, West Wing (Q1932621) 
Oppose Per above, this property is already existing, you might want to request another property for the number of physical platforms. --Liuxinyu970226 (talk) 09:01, 2 February 2017 (UTC)
Delete Given that the existing data can't be trusted to have a consistent meaning because of the name change. It's unfortunate but I don't think there's a way to transfer the existing data over in a way that won't leave a lot of errors. ChristianKl ❪✉❫ 13:14, 23 December 2017 (UTC)
Neutral I think generally, use of located in/on physical feature (P706) should be expressive enough. The property may be useful in some cases, but I do not support imposing on using it. – Susanna Ånäs (Susannaanas) (talk) 04:33, 15 May 2018 (UTC)
Support Looks fine for me. Bencemac (talk) 06:47, 8 August 2018 (UTC)
Conditional support On the condition that the new property proposal passes and we migrate all existing uses of this property to the new property. Deryck Chan (talk) 10:29, 2 August 2018 (UTC)
Not done Withdrawn. Lymantria (talk) 17:48, 10 December 2018 (UTC)