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.
There was already a discussion about deletion of these properties and decisions have to be taken on a logic way as properties are the ground of classification in Wikidata:
If there is an original language, we have to keep a symetric classification with an original publisher, an original publication date,...
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
@Jura1: In case you didn't read the long discussion before just know that the discussion above was about merging 2 properties. But since the beginning of this discussion we have a new property so all votes are outdated due to the fact they were based on only 2 properties. If you assume that the above discussion can still continue please contact all contributors who took part to the discussion in order to ask them to reconsider their vote according to the new situation. New situation means new discussion in order to offer the possibility to everyone to change its previous position due to the new elements. Snipre (talk) 09:05, 7 June 2016 (UTC)
This was already closed. If you think the other discussion had been closed prematurely, you might want to contact its closer. There isn't really much in your argument that hadn't been brought up before. If you duplicate discussions you are merely disrupting the project. --- Jura16:35, 11 June 2016 (UTC)
Again I have the impression you didn't understand the situation of the previous discussion so please have a look at it:
1) another contributor (Srittau) asked for new discussions mentioning the change of the situation
2) the admin who closed the previous discussion proposed to open new deletion requests too if desired. Three contributors having a similar position against you alone, I hope you agree this is not a me-against-you argument
3) the previous discussion was closed as undecided and not as keep it so reopening the discussion is not forcing to change a decision: to change a decision we should have a decision and this is not the case.
4) the situation is different from the previous discussion: the merge proposed in the first discussion implied to modify both properties. Now with the third property it is possible to keep untouched one of the two properties and to delete the other one. So this is a new possibility which was not analyzed by the contributors who gave their opinion. Snipre (talk) 12:57, 13 June 2016 (UTC)
It was explicitly asked to close the discussion Jura mentions as reason to close these requests. There was a good reason to indeed close that discussion, as situation between start and end of discussion was changed dramaticly. Initially there were two "language" items, but in between a third one was created, which could be seen as a merge of the two earlier ones. Discussion was contaminated by this change of circumstances. This can clearly be seen from the before last statement, asking for merging of the properties, while a merged property was already available. I think my closing statement was clear about no decision being taken. Although you may argue if a closure without decision can be allowed or should be interpreted as a "no consensus, so no deletion" decision. The latter was, as clearly stated, certainly not what I intended and no-one came to me to discuss about that point. From that point of view, I feel some disappointment about these speedy closures by @Jura1:. Lymantria (talk) 13:50, 13 June 2016 (UTC)
There isn't really much good to come from three open discussions on the same topic (which is why I closed two of them). It's really disappointing to suggest that we should hear the same arguments all over again .. --- Jura14:00, 13 June 2016 (UTC)
We now have zero of them left, so there may be opportunity to open one once again. Snipre may have been premature with his opening here before closure was done. Lymantria (talk) 14:19, 13 June 2016 (UTC)
Why didn't you take into account in your closure that the other property was created and discussed at length when the previous deletion was open? Snipre even intervened there. It might be that your closure was premature or incomplete. --- Jura14:30, 13 June 2016 (UTC)
What suggests you that I didn't take that into account? How can a closure of a discussion that turned into a mess be premature, if it does not contain a decision? Lymantria (talk) 15:16, 13 June 2016 (UTC)
@Jura1: Since when the mood of one contributor defines what can be discussed or not ? If you are tired of that discussion just leave and let the other people discussing. Your comment just proves that your action was not based on any good reason but only on your personal jugdment. So again 3 contibutors propose to discuss again ayou are until now the only one who raise an opposition to a new discussion based on your mood (It's really disappointing to suggest that we should hear the same arguments all over again). If you already have a solution please share with us your great knowledge and explain us how do we have to use the three properties.
Just try once to be a little consturctive and say me what I have to do when I have
P2439 (P2439) defined as "any item that has or uses a language except works or persons, like names, words, phrases, proverbs."
language of work or name (P407) which according to its label can be used to describe the language of a work and a word like a name
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
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.
That seems like a intensive task. It should be easier to make items while adding claims first. Is there more discussion about this? And please inform others on the property talk page. Sjoerd de Bruin(talk)10:13, 7 November 2016 (UTC)
Keep I don't think we should make items for individual burial plots in cemeteries and you haven't provided any reason why we should. - Nikki (talk) 10:40, 10 December 2016 (UTC)
Keep I believe usually (not always) it is not a good idea to create a dedicated entity for grave. P1442 is convenient for specifying an image in commons, and useful for distinguishing from P18 Eran (talk) 19:07, 31 December 2016 (UTC)
Comment I Oppose the motivation as such, it makes it more complicated than necessary. I see an option to add P18 as a qualifier to P119. But that denies us the option to add a "label" to that picture. -- Innocent bystander (talk) 10:34, 4 January 2017 (UTC)
Keep Requiring a separate item for the graves of deceased people seems excessive. (In some cases it might be appropriate, such as if the person's grave is particularly noteworthy, but it shouldn't be necessary except in those exceptional cases.) SJK (talk) 04:29, 6 January 2017 (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.
Wholly redundant to member of (P463), which is for membership of "a specific organization". That the organisation in question is a political party (or not) can be determined from its instance of (P31).
Yes, there are a lot of potential problems with P102. One is that the adding of this property into a database like Wikidata could be illegal where I live.
Another is that if you have a seat in a national or local parliament for a political party, does not mean that you have to be a member of that party. -- Innocent bystander (talk) 11:05, 13 November 2016 (UTC)
@Pigsonthewing: (Failed to see your Q until now.) The relevant law is Q10726917, which is a part of the Swedish constitution. Adding membership of political party into a database is definitely problematic. If I remember correctly, both the Security police and the national railway company have been caught doing this. And the only intension of this by the railway company was marketing toward group travellers. Not only membership of a political party can be problematics, but all records of political opinions. -- Innocent bystander (talk) 08:31, 24 December 2016 (UTC)
Frankly this is irrelevant for Wikidata. That the Swedish national railway company is using political party affiliation as part of its marketing campaign is bad, but Wikidata is only storing political party preference for people who are either politicians standing for office, or notable people who have declared their party membership (plenty of celebrities and columnists describe how they are registered members of some party or the other). In both cases, that is public information that has been published in a source. Just the same as with data on religious belief, sexual orientation and so on. —Tom Morris (talk) 15:16, 3 January 2017 (UTC)
@Tom Morris: That somebody is "standing for office" for a political party, does not prove that they are members of anything. It still happens in local elections here that some people got elected for a political party they are not a member of. In one case, a V-supporter wrote his own name on a SD-ballot and succeeded to get a seat representing a political party he hates. It is one thing for a political party to win X seats in an election, another thing to fill those seats with supporters and a third thing to keep them loyal to the party for four years. On county-level that last thing has become a huge problem for the governing majority here. -- Innocent bystander (talk) 10:52, 4 January 2017 (UTC)
@Innocent bystander: That seems a pretty niche problem. In contested situations like that, we simply do not include that on Wikidata and rely on Wikipedia to explain the context in prose. Apply Pareto's Principle: in most cases, if someone says "I'm a member of the Labour Party", they probably are a member of the Labour Party, and in most cases if they are on a ballot with an 'R' next to their name, they are a member of the Republican Party. In Rio de Janeiro, a monkey called Tião from the Partido Bananista Brasileiro (Brazilian Banana Party) 'campaigned' for the mayoral election on a platform of "Vote money, get monkey". Amusing though that is, we shouldn't build our Wikidata representation of things like politics and elections around protest candidates, joke candidates and monkeys running for mayor. We can handle these kind of odd exceptions with other constructions rather than by deleting P102. —Tom Morris (talk) 11:44, 6 January 2017 (UTC)
@Tom Morris: That somebody "steals" a seat in this manner is very unusual. But that somebody "represents" a party they are not member of is more common than most of us think. Sometimes you vote for a list of persons on a list with mixed persons. They represents "The conservatives", but "The conservatives" is not a political party. It is a technical cooperation between close related parties. The voting-system here favours large parties at the cost of the small ones. When I have looked into old statistics, I see that list A got 5 seats, 3 members of S and 2 of V. List B got 5 seats, all to S. List C got 6 seats, 4 to C and to to 2. List D got 3 seats, 2 to H and 1 independent. When I moved here, SD had one seat in the local election, but no names could be found in the ballots. The seat became empty.-- Innocent bystander (talk) 12:19, 6 January 2017 (UTC)
There are really two slightly different concepts wrapped up together here — a person choosing to be a (paying / voting / supporting) member of a political party (which can be an entirely private matter, but which some people make public: e.g. Eddie Izzard (Q254022) being a member of Labour Party (Q9630)), and an elected politician holding office as a representative of a party. Most of the uses of member of political party (P102) seem to be the latter, but I suspect it would be better to have that as a qualifier on position held (P39) instead (which would also better handle the cases where someone holds two different offices simultaneously on behalf of two different parties), leaving member of political party (P102) free for the former — and which would then probably be so infrequent as to be moved to member of (P463) per the suggestion. --Oravrattas (talk) 15:39, 1 January 2017 (UTC)
Oppose Is it really a good idea to delete more specific properties and link to general properties. I don't see the reason. The more specific properties allow us to have the redundancy that is necessary to catch outliers/errors. In some instances any queries (SPARQL) will be simplier when we have specific properties. We also have member of sports team (P54). Should this property then also be deleted? — Finn Årup Nielsen (fnielsen) (talk) 17:29, 21 November 2016 (UTC)
Keep Seems a reasonable subproperty of P463. Privacy concerns are no more reasonable than those that could be presented for religious affiliation, sexual orientation etc. —Tom Morris (talk) 11:46, 6 January 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.
Well, we would need two properties: "ISO standard this is standardized in" and "this is the item for ISO standard #1234". This property could be repurposed for the latter. Also, we should have the replacement items first, before deleting this one. --Srittau (talk) 11:57, 18 May 2016 (UTC)
Were we to pursue the action of repurposing (which I think I support), I would suggest a rename as well to "standard number" or similar, so that we can apply this outside the realm of ISO with e.g. MIL-STD. --Izno (talk) 12:11, 18 May 2016 (UTC)
@TomT0m: I vaguely recall asking if this property existed a while ago, heh. It has the wrong domain for the question at the time. That said, oppose deletion per Srittau, and support a new property (if necessary) called "specification"/"specified in", for the same domain as P503 with item datatype. --Izno (talk) 12:11, 18 May 2016 (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 sure if the right entity can be determined conclusively through checking a series of other items and properties. --- Jura16:24, 4 August 2016 (UTC)
Keep An exclave is a territory located separately from the administrative entity to which it belongs, but which does not belong to another administrative entity. For example, Llívia (Q13745) is a territory located in the interior of France, but that belongs to Catalonia and is administered by Catalonia. The property exclave of (P500) Catalonia, serves to indicate that it is a territory separated from Catalonia but that belongs administratively to this region. In the case of property located in the administrative territorial entity (P131), it serves to indicate where it is located, but not to which administrative entity it belongs or which is a separate territory. --Tximitx (talk) 22:39, 6 February 2017 (UTC)
See the usage notice of P131: "You only need to add the most local parent admin territory, but check that that item also has a P131, with the next level, and so on." For an exclave, the value of P131 is the most local parent admin territory where it is located. to indicate that is a separate territory we already have instance of (P31) and enclave within (P501).--GZWDer (talk) 19:52, 14 February 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.
Weak oppose certainly on UK trunk routes "primary destinations" are a specifically defined subset of places served - e.g. M5 motorway (Q1824663) has 12 primary destinations but serves dozens to hundreds of places of various sizes depending how you look at it. I can see value in broadening place served by transport hub (P931) to something like "place served by port, airport or station" but I don't think merging it with a specific property is the best way forward. Thryduulf (talk) 20:53, 15 August 2016 (UTC)
Keep Not convinced that the two mix well. P931 is for placed next an airport, the other for destinations. -- --- Jura19:11, 15 January 2017 (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.
Keep - launch point is a subproperty of starting point, the constraints are different are therefore is very useful to keep it. —surueña11:08, 17 August 2016 (UTC)
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! Eran (talk) 12:19, 9 Septemberp 2016 (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 "landing" may refer to the return, not the destination of the mission - specifically this is how it has been used here for space shuttle flights. I don't think "start point" "Kennedy Space Center" "destination point" Vandenberg airforce base, is what you would expect for a description of a space shuttle flight. Leave location of landing (P1158) as it is. ArthurPSmith (talk) 14:42, 4 August 2016 (UTC)
Keep I recommend keeping this one. The location of the landing of a spacecraft could differ from its destination point. For example, a Shuttle mission would have a location of landing of somewhere on Earth but could have a destination point of some point in space, the ISS or Earth depending on the mission and the definition. Reguyla (talk) 21:12, 13 October 2016 (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.
ah, ok. The change makes sense then. Is it actually possible to change datatypes (other than what has been done with external identifiers?) I think a completely new property would need to be created to replace this one, and the entries migrated. ArthurPSmith (talk) 20:36, 5 August 2016 (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 is too difficult to apply and virtually not used anyway (only three times since its creation in January)--JakobVoss (talk) 19:06, 15 August 2016 (UTC)
What's interesting in this proposal is that ... it was said that there would actually be only a few statements with this property if I recall well. But community approved it knowing that. This makes this deletion proposal even more puzzling to me. author TomT0m / talk page20:31, 15 August 2016 (UTC)
Oppose A few use is not really a good reason to oppose. Plus I'm puzzled by Jakob gave another reason in Wikidata:Property_proposal/lower_rank_than : this would be a specific case of a more generic property. But the generic case would be more easy to apply ??? I'm puzzled. Where is the consistency ? author TomT0m / talk page20:06, 15 August 2016 (UTC)
Also, why launching this proposal before the discussion on the other one is not finished and the not-so-equivalent alternative is not even and might not be created ??? This gives me a really bad taste in the mouth. author TomT0m / talk page20:11, 15 August 2016 (UTC)
If a property is used only three times in half a year, I see little practical acceptance nor need of it. I would welcome a more general and less difficult to apply property, such as "subordinated", that subsumes the other proposal, the original intention of P2445 and other (too special or complicated) cases of hierarchical relationships. -- JakobVoss (talk) 20:28, 15 August 2016 (UTC)
No, that does not subsumes meta subclass of as there is information implied by meta subclass of. If A is a metasubclass of B then an instance of A is probably a subclass of an instance of B, which can't be known by this generalisation. And it was already known at the proposal times that there would be just a very few statements with this property. author TomT0m / talk page20:35, 15 August 2016 (UTC)
Keep per TomTom above. It's worth reviewing first what the relationship is that this property tries to capture. Consider the following diagram. The P2445 'metasubclass' property, with A metasubclass of (P2445) B implies an arrangement like the following,
A ....> B
^ ^
| |
| |
----> M ----> N
so M is a subclass of N, but the classes M and N are also usually instances of items A and B -- something in itself quite rare; but even more rare if A is not a subclass of B. P2445 exists to present the connection between A and B in such a case, ie that instances of A are likely to be subclasses of classes that are instances of B; but A itself is not a subclass of B.
Yes, the property is used on very few items. But this is not (really) because nobody has been bothered to populate it. The truth is, as TomTom noted above, there were only ever expected to be a handful of examples (the original property proposal in fact spun out of a discussion as to whether this kind of structure could exist at all).
Having found such examples, the easiest way to record them is in the database itself, and so this property. It also acts as a prompt, that a class M that is an instance of item A should well perhaps have a subclass relationship with some class N that is an instance of item B.
There may indeed only be a handful of items A of this kind, so only a very limited number of potential uses of the property. But that was known from the start, and seems not a particularly good reason to delete it. Jheald (talk) 21:34, 5 February 2017 (UTC)
Keep I see (and have now added to property examples) that there is another place where this property is being well-used:
Why would we want to remove the ability to represent this "meta-relationship", unless someone knows a better way to represent it? Per postings above, subclass of already has a meaning that (even when applied to two metaclasses) is not equivalent to metasubclass of.
Comment (addding): Also, there's no real reason to remove it unless it were being misused a lot more than it is being used correctly, or unless it were causing serious problems (other than the purported "problem" that it might be used infrequently or that there are some people who won't use it because they don't understand it, while others will and do). DavRosen (talk) 15:43, 10 March 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.
Process for this should be made clear somewhere, on the Project Chat I have been told the first step for this is to propose the deletion. Requests and procedures on Wikidata seem to be all over the place and very unorganized. Amqui (talk) 16:40, 19 September 2016 (UTC)
I do not favour the deletion of this property and its replacement with the alternate proposed property. This property is simple and easy for the addition of a general street address to qualify a birth or death location, and additional components just complicates for no expressed benefit. — billinghurstsDrewth06:43, 5 November 2016 (UTC)
I read this request as a difficult way to actually rename the existing property. Moving the contents to a new property will not improve anything. And yes, for me address and located at street address is the same. Are there occasions where it's different? Edoderoo (talk) 19:08, 21 November 2016 (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 not sure I see a practical difference between "topical page" and "semantic information" at least in this case - basically both are controlled vocabularies that define a subject area on which the NY Times has published. Wikidata items are semantic concepts in themselves, so however we link NY Times data to wikidata in practice what we're doing is linking it in to the semantic web. ArthurPSmith (talk) 14:18, 30 September 2016 (UTC)
Comment The formatter URL for these properties is not working. If the properties stay, it should be fixed. --- Jura08:17, 1 October 2016 (UTC)
I mentioned that in my initial deletion comment. I don't believe the formatter URL is fixable, there doesn't seem to be a way to access these concepts without the developer key. ArthurPSmith (talk) 18:21, 3 October 2016 (UTC)
An external identifier doesn't need a formatter url. The property could exist without a formatter URL. There are obviously other reasons why this property could be deleted. --- Jura06:05, 6 October 2016 (UTC)
The data set is not closed; it is open to anyone with an API key. Please point to a policy requiring the data sets to which we link to not have that requirement. And please justify your "unfit" claim. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits15:17, 5 October 2016 (UTC)
The dataset is closed with a personal API key. You can not link to the information without your personal API key. --Succu (talk) 16:05, 5 October 2016 (UTC)
@Succu: perhaps the main concern is the terms of use? Though I haven't read carefully, I assume we can't just register a key for "wikidata" and insert that into all the formatter URL's for everybody to use? Do the terms of use even allow extracting the concepts into wikidata? Not clear to me what the licensing constraints actually are. ArthurPSmith (talk) 13:16, 7 October 2016 (UTC)
Delete we should only link to open databases. A database which requires an API key to read the data is against the spirit of providing free knowledge to everyone. --Pasleim (talk) 11:57, 12 October 2016 (UTC)
Delete in its current state. If they open it (more) widely, ie. suitable organisational access, then we can review. We should be encouraging open datasets! To "Pigsonthewing" this is not case of looking for prescriptive "blackletter policy", it is about usability and functionality, and the project's ability to make a reasoned determination where a dataset is functionally closed for the purposes of our project. If they want in, they can read this discussion and look at what they want to do. — billinghurstsDrewth04:55, 16 January 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.
See discussion at https://phabricator.wikimedia.org/T145284 (pinging Yurik, Jura1, MaxSem and Kolossos). Wikidata item IDs can already be found in OpenStreetMap (and can be pulled by an API), and since OSM IDs are more flexible there's no point in having the information here as well because it's more likely to become outdated. In addition, only relations can be linked to with the property (because of volatility of other OSM objects), which is another inherent drawback. —Jc86035 (talk) 14:27, 5 November 2016 (UTC)
Delete 100% agree, we should encourage Wikidata ID usage on OSM side, and possibly even help with our bot running prowess to convert all existing "wikipedia" tag to "wikidata" tag. P.S. the data should be moved to OSM before being deleted. --Yurik (talk) 14:46, 5 November 2016 (UTC)
Delete To start, I must say that I agree on the subject matter, and have kept it as my guideline over the years. However, I see great difficulties for non-coders, to make a combined query in OSM and Wikidata. What if OpenStreetMap relation ID (P402) was automatically, regularly updated by a bot? Perhaps both ways, also the Wikidata ID in OSM with fresher data from Wikidata. I fear that playing around with this data will only be available for few. --Susanna Ånäs (Susannaanas) (talk) 15:09, 5 November 2016 (UTC)
Susanna Ånäs (Susannaanas), if I understand you correctly, your objection is about tooling, not the database storage. And tooling can be greatly improved without the need to duplicate data. Data duplication produces inconsistencies and errors, as you will no longer know which data is authoritative, and some changes may be introduced in both. I suspect that it would be relatively easy for the overpass API to support Wikidata. Moreover, I would insist we should improve all other OSM-related tooling to natively support Wikidata, as that will allow much richer meta-information querying. The US governor map example is exactly that - a mixture of OSM and Wikidata that the less technical (SPARQL-only) community can use. We should do more of this kinds of tools. --Yurik (talk) 18:47, 5 November 2016 (UTC)
I would be more than happy to vote for deletion, if the connection would work ubiquitously. I am however one of those less technical, and I possibly cannot make fool-proof arguments. When I was creating the Wikidata IDs for Finnish municipalities in OSM for a classroom assignment (they are still not all there), I would have needed a combination of Overpass + SPARQL to sort out which links between Wikidata and OSM were missing. That was beyond my skills. I could have used the Wikipedia data of the municipalities and made a query for those with a missing OSM id. But thinking how I would do it in OSM, or programmatically add those in OSM would be far too complex. So yes, it's about tooling, but in many ways. --Susanna Ånäs (Susannaanas) (talk) 20:31, 5 November 2016 (UTC)
Delete P402 have never made sense to me because it's only in rare cases there is a actual relation in OSM and not a node or way. Using the Overpass API is a much better solution. --Abbe98 (talk) 17:58, 5 November 2016 (UTC)
Comment Made up queries ("The original search was: “wikidata=Q874373”) make no sense, who would query the Eiffel Tower by wikidata=Q243.
Few users would know id of Effel Tower in Wikidata. It is hardly usable, unless you know every id in Wikidata.
Then, how overpass can replace current http://query.wikidata.org/ ? It makes querying Wikidata more complex, not simpler.
IMO it is too early to speak of replacement, until users are okay with implied penalty when it comes to federated SPARQL services. d1g (talk) 15:33, 28 November 2016 (UTC)
@Jklamo: See below; we can query their database for each item instead. As a counterexample to administrative boundaries, public transport relations are often deleted or even repurposed (since there are two different schemas, one deprecated). In addition, even if other databases link back to Wikidata, any Wikidata editor can also edit OpenStreetMap and vice versa, making it useless to have two copies of the same data by two overlapping groups of editors. Jc86035 (talk) 10:52, 13 November 2016 (UTC)
@Jc86035: I cannot see any comparable alternative. OpenStreetMap relation ID (P402) allows simple direct link from wiki to OSM without need of querying, 3rd party tool/services, gadgets or mw extensions. OSM relations may be unstable if they are incomplete, so mergers are sometimes necessary, but once relations are complete, they are pretty stable. Even for public transport relations - just random example from my country here - osm relation of Prague tram line no. 3 is 5 years old. Note also that at the moment OpenStreetMap relation ID (P402) is used mostly for administrative boundaries and streets (see query). --Jklamo (talk) 00:06, 14 November 2016 (UTC)
@Jklamo: But what's the point of having it if our dataset is only about one-quarter the possible size of theirs and we can easily access theirs? It's kind of like having old-style interwiki links, but only having them for one namespace on one of the wikis. Jc86035 (talk) 05:13, 14 November 2016 (UTC)
Comment > but once relations are complete, they are pretty stable. ... osm relation of Prague tram line no. 3 is 5 years old
Completely agree with @Jklamo:, I have same experience with objects I edit or watch. Tram/metro infrastructure is very stable.
"Keep history" is a good practice in OSM. Experienced users won't change ids every time they touch objects (nodes/ways/relations).
Bus schedules and detours change frequently sometimes. Discussions stability of bus route id (both in WD or in OSM) won't lead to any meaningful results to the end users (both WD or OSM users).
Public transport schema was established in 2011 (route_master=*). We can't retag objects quirkier than what we have or we don't have local knowledge.
Keep From the users' comments above, I take it that these links are stable. That OSM links to Wikidata is a good thing. There are several other databases that link to Wikidata, but we still don't remove them from here. --- Jura10:23, 13 November 2016 (UTC)
@Jura1: Even if relations are stable, it doesn't change the fact that in OSM relations make up about 0.1% of objects, and we can't link to any of the others because they get deleted all the time. They can link to our database, and here items get merged much less (and redirects are kept). Jc86035 (talk) 10:46, 13 November 2016 (UTC)
That's still 4.5 million relations. We don't really have that many more items that could get coordinates/such identifiers. --- Jura17:07, 13 November 2016 (UTC)
@Jura1: Using more useful data, there are three times as many nodes and ways with Wikipedia/Wikidata tags as there are relations (see Key:wikidata). If they have a more complete dataset, we may as well just use theirs. Jc86035 (talk) 05:13, 14 November 2016 (UTC)
I'm not saying that for your non-Wikidata specific application, you can't use a third party service for better coverage. For many identifiers, the source site holds more data than Wikidata. This isn't a problem as such. Besides, in this case, it's not possible that there be three times as many items linked once we have 4.5 million relations: Wikidata simply doesn't have 1,000,000,000 items to start with (in case you wanted to link every node to a Wikidata item). --- Jura08:36, 14 November 2016 (UTC)
@Jura1: The fact remains that many objects, like almost all villages and towns which don't have administrative boundaries (as well as most buildings, beaches, small islands, parks, forests, lakes, rivers and sports grounds), are never going to get their own relations because there's no need for that to happen. Of course, it might end up being the norm for relations to be created entirely for the purpose of linking from Wikidata to them, but that'd just be a massive waste of time because we can already link the other way. Jc86035 (talk) 13:44, 20 November 2016 (UTC)
That is the question that was at the beginning of this request. The conclusion is that it's actually stable. A third party service is offered as replacement, however, I don't know about its stability. --- Jura22:40, 21 November 2016 (UTC)
@Jura1: I literally just had to change the relation ID of a route because an OSM editor changed the relation referring to the entirety of it with another one. If we had a bot to go around and check for these changes (like the old interwiki bots), then ideally we would have properties for OSM nodes and ways as well, but there obviously isn't such a bot right now and I'm not sure how much support making one would have. Jc86035 (talk) 12:35, 27 November 2016 (UTC)
Weak oppose (changed from "Keep") I would like for us to link to OSM too, not just the other way around, as it makes some queries simpler from Wikidata. But I don't sufficiently grok the different properties needed for that, and I have the feeling that some people in the OSM community seem to be opposed to have datasets uploaded. Before these datasets are lost, I'd like to see them added to Wikidata and preserved. But I have not sufficient background on the relation between Wikidata and OSM, and how OSM is doing things. (The rest is old comment) OSM seems to be reluctant to accept Wikidata IDs and, even if in, rather quick in deleting them again, which leads to a loss of information. Even if the IDs are not 100% stable, we can at least save them here. The important thing is that these IDs are not reused, even when they change, so that we don't accidentally link to the wrong thing. I would suggest to keep this property here and to extend its coverage considerably. --Denny (talk) 22:51, 28 November 2016 (UTC)
OSM is not reluctant to accept Wikidata IDs. One OSM editor has recently thrown his toys out of the proverbial over a set of automated edits that, he claims, broke the letter (not intent), of OSM's automated edit policy, but other such edits have not been problematical, and the number of Wikidata IDs in OSM is growing steadily and at an accelerating rate. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits15:39, 2 December 2016 (UTC)
@Denny: OSM does not seem reluctant to accept Wikidata IDs to me. In fact, the default editor on their website (iD) automatically adds Wikidata tags whenever someone links to Wikipedia (see this blog post for a demonstration). It's mass automated edits that (some) OSM people don't like. - Nikki (talk) 18:01, 2 December 2016 (UTC)
Delete I am in favour of changing the current situation, either by deleting P402, or by adding properties for linking to ways and nodes (which has been rejected multiple times). Anyone who wants to get links between Wikidata and OSM can't rely on our data because it deliberately omits most of them and so will need to query OSM anyway. The data for this property is unreliable too, because people keep using it to add IDs of nodes and ways (e.g. Special:Diff/409526821, Special:Diff/398588794). - Nikki (talk) 18:01, 2 December 2016 (UTC)
If we delete all properties where our data might not be perfect and some other source provides a link to Wikidata, we might and up deleting most of our properties. --- Jura11:39, 10 December 2016 (UTC)
Slippery slope arguments are rarely good arguments. Nobody (except maybe you) is going to propose deleting everything just because one thing is judged to better handled in a different way, so that does not seem like a valid argument for keeping the property. - Nikki (talk) 12:50, 10 December 2016 (UTC)
I did not argue that we should remove it because it needs maintenance and if you think I did, you've misunderstood what I said. My argument is that the current status - disallowing most links while allowing a small subset - is fundamentally flawed and that would not change even if our data were perfectly maintained. - Nikki (talk) 12:32, 14 December 2016 (UTC)
Delete We are steadily adding Wikidata identifiers to OSM, and extracting information from OSM to build a service is way easier (the WMF services are already doing it I believe). IDs aren't guaranteed to be stable (the argument "it's stable since x years" is invalid IMHO, because it covers only a small fraction of possible Point of Interests: museums could be represented either as nodes, ways or relations, and moving the information from a node to a way it's a common operation which changes the ID). Having a process that runs on the current OSM data could also help mantain Property:P625 with a bot --Sabas88 (talk) 17:23, 10 December 2016 (UTC)
@Jura1: I don't think so, although it might be a good idea to notify either the OSM wiki's community portal(?) or the talk mailing list, as I haven't done that yet. However, many of the participating editors, including myself, are also OSM mappers. Jc86035 (talk) 06:55, 14 December 2016 (UTC)
@Thierry Caro: But you are aware that keeping data which might be outdated unnoticedly might not be a good idea? For example, say the building of a reputated organization which has a Wikidata entry consists of a (multipolygon) relation. Consider further that someone then thinks that a MP is not the way to go, because the building has a quite simple shape and turns it into a way, discarding the multipolygon. And voilà – the data inconsistency is gone. Thus a Weak support from me. --Glglgl (talk) 16:04, 14 December 2016 (UTC)
Comment OpenStreetMap regular here - Wikidata IDs have been added to OSM objects en masse in the past weeks without the requisite discussion on OSM side; more than 100,000 by Yurik alone. These additions have been overwhelmingly been automatic (based sometimes on existing Wikipedia links, sometimes on name/type/coordinate matching) and are of sub-standard quality for OSM (because they have been mostly done by people without local knowledge who did't understand the difference between two similarly named administrative entities that share a Wikipedia but not a Wikidata entry etc). It is therefore not a given that these links will be allowed to remain in OSM, and if they are, it is quite possible that data consumers will shy away from using them because of the sub-standard quality. 193.60.236.1315:19, 14 December 2016 (UTC)
Hi, just to clarify - I have posted about it to the OSM talk list, and I only converted existing Wikipedia links into their corresponding Wikidata IDs. I know others might have done more "risky" edits such as auto-discovering corresponding Wikipedia article, but in this case, each Wikidata item corresponds to exactly one Wikipedia link, so this is more like locking the WP link in place, in case the article gets renamed. Similarly named places don't really relate to this issue, unless both places link to the same Wikipedia article, so, by extension, they will link to the same Wikidata item. On the other hand, having Wikidata items allow for much better cross-site quality validation, because you can compare tags on the element with the statements in Wikidata. --Yurik (talk) 18:51, 14 December 2016 (UTC)
Further to Yurik's response: The IP's comment is ambiguous. When they say "not a given that these links will be allowed to remain in OSM" they refer to the specific subset of Wikidata IDs in OSM described in their comment, not to Wikidata IDs in general. The "sub-standard quality" bar is pure FUD. I too, speak as an OSM regular. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits23:27, 14 December 2016 (UTC)
Keep. I think it's useful to have links to OSM from Wikidata, even if the reverse link is also present in OSM, partly because it's easier for data-consumers of Wikidata to use (not having to call a separate API), and partly because there might be some legitimate disagreement about what the 'right' concordance should be (e.g. Wikidata editors might link two different items to the same OSM relation, but OSM might only consider that a single Wikidata item should be linked back). OSM relation IDs are roughly as stable as Wikidata IDs (which can change, for example, if two items are merged, or one is mistakenly deleted and then re-added). The fact that some OSM nodes and ways don't belong to a relation shouldn't stop us having the property, particularly as I don't think there's any rule in OSM against adding a single way to a relation, for the purposes of adding semantic information to the relation. Frankieroberto (talk) 09:44, 6 January 2017 (UTC)
@Frankieroberto: I don't think there's a way of putting the information of a single node into a relation, because aside from this very narrow scope it would be completely pointless. This might be rather annoying for places that don't have exact boundaries, as well as things like trees which can't be tagged as areas. Jc86035 (talk) 09:13, 8 January 2017 (UTC)
A relation is simply an object which contains other nodes, ways and/or relations. You can have a relation with just one object (in fact, you can have a relation which contains no objects at all) but creating a relation for something which can already be represented by a single node or way is redundant (nodes and ways can have tags, so you don't need a relation to add semantic information) and doesn't add any value to OSM, so it's not something we should encourage people to do. - Nikki (talk) 11:56, 8 January 2017 (UTC)
@Nikki: I meant as in there isn't a valid relation type which could do that. You could have a multipolygon containing a single way, but there's no such way (AFAIK) to do that for a node. Jc86035 (talk) 01:17, 11 January 2017 (UTC)
@Jc86035: Ah, I think what you're saying is that there's no established use for a relation with a single node? (I wouldn't use "valid" to describe that, you're allowed to come up with new tags if you can't find any existing tag that fits). - Nikki (talk) 13:40, 11 January 2017 (UTC)
@Nikki: Whilst it might often be redundant in OSM to create a relation containing a single node or way, I don't think there's any specific rule or guidelines against it, and in practice it probably happens quite a bit. Eg the stop area tag is almost always applied to a relation, and whilst that normally covers at least two nodes (one for the stop on either side of a road), this isn't always the case. Frankieroberto (talk) 21:07, 16 January 2017 (UTC)
@Frankieroberto: I meant as in for general use cases (there's no multipolygon equivalent for nodes), for things like trees and other nodes which can't be mapped as areas. I suppose it's possible that we could make (for example) metadata relations where the only tags are type=metadata and wikidata=Qxxx, but it seems like a confusing waste of time. Jc86035 (talk) 02:38, 17 January 2017 (UTC)
Comment, right now I'm leaning on Keep. I don't really see the problem with this property. Redundancy: 100 % of Wikidata is redundant (we even give the link in reference to tell from where it's redundant). Pull from OSM: not really easy and you need a different tool (a lot of people have trouble using Query, learning yet another tool is not a good idea and - I find - overpass turbo to be particularly slow and complex to use; see my recent examples on Wikidata talk:OpenStreetMap). Unstable: all link outside (and even some inside) Wikidata are unstable, and OSM relations are quite stable. In the end, the deletion doesn't seems the appropriate answer for the question here, can't a tool/script/bot periodically check is the link is still ok? (like I said, it could be useful for other properties too). Cdlt VIGNERON (talk) 16:23, 9 January 2017 (UTC)
@VIGNERON: I think there are APIs aside from overpass which can pull OSM data, such as the one used in Kartographer, but in my experience Overpass is sufficient, if a bit clunky and slow. I believe there have been proposals to update data with bots before, but they did not pass and that's why we don't have properties for ways and nodes. A proposal to keep Wikidata synched with external databases (which would include OSM) is #36 on Meta's Community Wishlist Survey, but it's not likely to receive much attention. Jc86035 (talk) 01:17, 11 January 2017 (UTC)
Yes, Overpass is nearly almost ok and yes, there is probably hundreds of ways to pull from OSM, but that's beside the point ; I've got a problem with the « pull » itself; if you split the date in two places, it's way more complicated to do query on both of them. Update data by bots is at best complicated and often kind of stupid and I'm glad it did'nt pass, I asked for a « check » not for an update (and not only for OpenStreetMap relation ID (P402) but for all properties that generate links since most URL aren't stable, even less stable than OSM relations). Finally, Wikidata ID are not stable either, is someone checking on OSM side if the link are still valid? Cdlt, VIGNERON (talk) 11:10, 11 January 2017 (UTC)
@VIGNERON: I think you're better off asking someone else for most of the details, as I don't primarily edit Wikidata and don't run bots, but I think OSM editors are assuming that Wikidata QIDs stay there for basically forever and that redirects from item merges won't be deleted or usurped. Do Wikidata items get split often? Jc86035 (talk) 13:55, 11 January 2017 (UTC)
Not often but it happens (I don't know if there is stats on this matter, when I look in the deletion log - Special:Log - most of them seems just non-sense being rightfully deleted but I've seem some case where users delete instead of merging or even reuse and change completely an item, the latter won't show on logs and would be hard to track, impossible for a bot). Cdlt, VIGNERON (talk) 14:19, 11 January 2017 (UTC)
Keep What is the problem of having OSM relations numbers here??? It takes so little storage space in DB that the discussion about deleting the property seems to be largely irrelevant here... This is more of a chicken/egg problem - should Wikidata have OSM relations numbers or OSM relations have wikidata IDs on them??? An extreme resolution could be these would be deleted on both sides and then we would end up having NOTHING at all! Is this what you want? Or rather a little redundancy in having the information on both sides? Redundancy is never bad (it is actually desirable!!!) if one can bear the storage costs (the cost is negligible in this case). So strong keep from myself. --Kozuch (talk) 09:29, 17 January 2017 (UTC)
@Kozuch: it makes a lot more sense to only bother adding Wikidata IDs to OSM, because (a) Wikidata has only one type of entity which should be linked, and (b) you can't use the Wikidata property to pull OSM objects through Extension:Kartographer (which is why I started this discussion). Until we have bots to scour OSM for Wikidata IDs and conflicts/errors (and vice versa), the property's data is likely to slowly become outdated as well as polluted with way and node IDs. Your "extreme resolution" is a pointless strawman argument. I would argue that it's not necessarily good to have redundancy right now, because it's a waste of editors' time to have to add data to both projects (manually or semi-automatically). Jc86035 (talk) 10:59, 17 January 2017 (UTC)
Keep It's all very well to say we can use Overpass to obtain the link for a single OSM relation. But what if one to do a query, to eg identify all the items in a particular group of classes (which could be quite big) which are currently missing an OSM relation? With this property in Wikidata, it's easy. Without this property it is significantly hard. Overpass can return 1 OSM relation. But can it return 10,000? And can it do it within the time-limit for a WDQS query? Jheald (talk) 08:46, 23 February 2017 (UTC)
@Jheald: It is a cause for some concern, as the Wikidata and OSM databases are not really linked (no parser functions, limited querying outside the Kartographer extension's GeoJSON and the WD property, etc.). If it's a particular class of objects, you could search for OSM relations of that type which have wikipedia=/wikidata= tags and then compare them a list of Wikidata items. Maybe Overpass features could be ported over to WDQS, but I'm not really familiar with the latter. Jc86035 (talk) 08:06, 2 March 2017 (UTC)
Keep I think it is best to have bidirectional links between Wikidata and other services where possible. So if another service links to Wikidata, I don't think that is any reason for Wikidata to not link back. The maintenance issues could be solved with a bot to sync the two (i.e. bot can scan OSM for links to Wikidata and add the backlink from Wikidata to OSM if it doesn't exist). With linking only from OSM to Wikidata, people browsing Wikidata might not become aware that OSM has useful information on the item they are looking at. SJK (talk) 01:11, 12 March 2017 (UTC)
@SJK: I would agree in principle, but proposals for both a bot and node/way properties have already been rejected, and you'd need to find someone willing to devote their time to writing bot code for something minimally useful (both databases are publicly accessible and editable; the Kartographer MediaWiki extension already pulls data directly from OSM). We would also need the bot to edit on the OSM side, and as far as I'm aware there aren't any (approved) maintenance bots there yet. The best solution is probably to get the WMF/OSM developers to integrate the databases or provide more convenient links between them such as parser functions and automated display of data from the other database, but there's no guarantee that's ever going to happen. Jc86035 (talk) 13:55, 17 March 2017 (UTC)
Keep Even if I see sensible points on both sides, my opinion is leaded by 2 considerations. There is no stable spatial database. It could be very nice for us, but it does not exist. This kind of stuff refers to present; biographical, historical databases, which concern the past, are not concerned by this issue. A database based on (even partially) the space of today fatally goes obsolete, and as far as my knowledge goes perfection and eternity are no goals in the project. And pass the hot potato to OSM would only sweep the dust under the rug. Second, how many users can use queries, how many can understand the idea of a property referring to a relation id? Kumkum (talk) 11:38, 23 March 2017 (UTC)
Keep the current P402 while we create/populate a new property to contain "node/1" or "relation/1" values; then we Delete an old P402 as overly restricted. We need external links other than relations. d1g (talk) 12:48, 23 March 2017 (UTC)
@D1gggg: The issue remains that you would need a bot operating on both Wikidata and OpenStreetMap to keep updating all the values (node/way properties have already been rejected due to being too unstable). Jc86035 (talk) 09:16, 27 March 2017 (UTC)
Properties in WD were rejected in order to use (un)stable OSM data? Then OSM is stable for purpose of OSM-WD mappings, isn't?
We don't need to track 96% of nodes.
Right now it is impossible to write an OSM editor which would stream writes from OSM to WD (other than to relations). d1g (talk)
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.
Duplicates located in the administrative territorial entity (P131) - creating two way links is always error prone - there are 71,857 of P150, and 3,520,325 of P131, which means most of the time we only link one way, from child to parent. We can easily query the whole tree top to bottom using this query:
Sigh, this is a very fair point. Plus I can totally see the value in editing them all in one place (linked from the WP article) rather than editing all the different subdivisions one by one. User:Lydia Pintscher (WMDE) or User:Daniel Kinzler (WMDE), is there any way to solve this? Ideal case:
In the infobox, show the list of { ?item P151 Qnnnnn } subjects, but with additional condition (e.g. only those that are subclusses of an administrative district.
Easy to edit multiple items to add a property pointing to the given subject (editing the foreign key on subjects so they all link to the current one). This way info boxes would contain the list, but users can change it easily. TBD: what if that property is already set, but points somewhere else?
The only suggestion I have for doing this is to write a gadget that provides this kind of editing interface would be two write a Gadget that does what you suggest.
However, this isn't just about editing, it's also about showing a list of things in a single place. This is easy to do with an outside tool based on a SPARQL query, but we currently have no way to show the result on a wikitext page, now somehow on a data item. -- Daniel Kinzler (WMDE) (talk) 19:08, 26 November 2016 (UTC)
keep. P131 is used not only for administrative entities but for any geographic entities, for example: monument, building and so on. That's way there can be many "P131" links for some division but only a few direct P150 links. --Infovarius (talk) 15:33, 19 December 2016 (UTC)
Comment personally, I think we should do away with this, but apparently there isn't really a way around it: Keep --- Jura19:11, 15 January 2017 (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.
Keep Identifier for people named in Domesday Book (Q19867), the famous "manuscript record of the 'Great Survey' of much of England and parts of Wales completed in 1086 by order of King William the Conqueror", and so clearly useful. The target site offers linked, open data in JSON format. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits20:53, 5 December 2016 (UTC)
Comment it is unused (which is no reason for deletion) but probably not useless. @Pigsonthewing: I've looked into this database to see what can be done but I ended up a bit confused, the example is :
but there is nine ID for people with this name, why is that and how do you tell which is which? and in particular : how can a bot or a tool add the right ID to the right item? Cdlt, VIGNERON (talk) 15:02, 11 January 2017 (UTC)
Keep WD has a fair number of entries for 11th century Anglo-Saxons and Anglo-Normans. In many cases they are identified as holders or tenants of particular lands in Domesday. Yes, the property still needs to be populated (and IMO we may need to be quite careful to restrict to only identifications that have reasonable certainty). But it will then be quite valuable to see where the lands held by a particular individual we have an article on actually were; or, in the opposite direction, where individuals in the OpenDomesday database can be linked to Wikipedia articles. (And/or to other databases we may have identifiers for). Jheald (talk) 16:18, 17 January 2017 (UTC)
Keep. Wikidata is a work in progress, and this property has a clear use. That it isn't widely used yet is not a reason to prevent its use in the future. Thryduulf (talk) 09:20, 12 April 2017 (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 I see, thanks for the clarification. Still the property holds exactly 0 instances and points to the wrong subject item. --Marfi (talk) 15:40, 12 December 2016 (UTC)
Comment it was created just last month. If it's still not used in February, I think we should double-check it. --- Jura18:11, 12 December 2016 (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.
Comment @ArthurPSmith: Volume and capacity are not the same thing, e.g. a lift with a capacity of 8 persons is not a measure of the lift's volume, same applies to TEU capacity, it is not a measure of a ship's internal volume. So, replacing this with volume as quantity (P2234) is somewhat muddled up. – The preceding unsigned comment was added byDanrok (talk • contribs) at 21:25, 17 January 2017 (UTC).
Delete. No current use (and little evidence of past use). Use volume as quantity (P2234) + unit twenty-foot equivalent unit (Q488021). That property is officially labelled "volume as quantity" with alias "tonnage" so it's reasonable to use it for capacity. There may be a case of starting a new property called "Cargo capacity" which can take either volume, mass, TEU, or even dimensionless tonnage as units, but we can have that discussion later. Deryck Chan (talk) 12:36, 7 February 2017 (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.
Keep As I've said in similar cases previsouly, we should not delete data when this kind of thing happens. Just remove or deprecate the formatter URLs, or update them to an archive like archive.org Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits17:50, 13 January 2017 (UTC)
Keep what the hell? How have I not been notified? All IDs work with the Hungarian links, and huwiki heavily relies on them. It's the most popular film database here, check Alexa for Hungary. There are no plans to close the Hungarian edition too. – Máté (talk) 16:21, 2 March 2017 (UTC)
Keep must be some kind of unfunny joke. This is the most referenced Hungarian movie database. Also they were always been historically friendly towards Wikipedia, and have provided lots of data for us. --grin✎11:42, 24 March 2017 (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.
Keep. When it comes to hotels, there is no better source for up-to-date information about the services and equipments on offer than websites such as booking.com (Q4035313) and the likes. Advertising is in the intent. We only judge the content. Thierry Caro (talk) 22:38, 10 February 2017 (UTC)
Keep Why is the fact that there's a commerical interest a problem. I think the website has an interest in providing truthful information. ChristianKl (talk) 22:39, 10 February 2017 (UTC)
Keep. I think this is useful for WV. We have property links to a great number of proprietary databases. As long as the IDs are stable it's fine to have them. Deryck Chan (talk) 13:04, 13 February 2017 (UTC)
Keep. As per everybody else. The issue is whether the external database is one people might find useful to link to, and whether the identifier is stable. Jheald (talk) 20:55, 13 February 2017 (UTC)
Delete 1. Advertising. 2. it's not a reliable source of information (clearly it's a conflict of interest to provide neutral information and try to sell the product at the same time).--Zeroth (talk) 02:20, 17 February 2017 (UTC)
Comment I'm not sure I'm understanding the objection here. So what if the site's purpose is to advertise/promote the facilities offered by the hotels? (And presumably to take a percentage of each booking made through it?) So what? Why should that be an objection? Jheald (talk) 09:15, 17 February 2017 (UTC)
Keep 1. The criteria of advertising and conflict of interest in Wikivoyageis much lower than Wikipedia and Wikidata have no conflict of interest rescriction. 2. Not every Wikidata properties indicates reliable sources.--GZWDer (talk) 10:52, 17 February 2017 (UTC)
Comment Has anyone sought the opinion of Wikivoyages on this matter? Part of our role is to support the wikis to have infoboxes, and if they use the id, then we should support it. Just like images/files in use at Commons by other wikis puts them within scope as long as licensing requirements are met. So if used by Voyages, then keep; if not used, then delete. — billinghurstsDrewth23:59, 19 February 2017 (UTC)
In the Russian Wikivoyage we do not use this property. One needs to ask at the English Wikivoyage, I do not know whether they use it.--Ymblanter (talk) 14:50, 20 February 2017 (UTC)
In the German Wikivoyage we are planning to support this and similar properties. We already widely use Wikidata. In some cases we have several hundreds Wikidata calls per article. --RolandUnger (talk) 07:55, 4 March 2017 (UTC)
Comment "collects to much personal information" - we shouldn't add/remove external ids in order to support/punish companies for their moves. d1g (talk) 08:55, 3 March 2017 (UTC)
Keep count me as "keep" for any RFD of an active booking/publishing business: few of them would shoot their foot and allow inaccurate data for prolonged periods of time. d1g (talk) 08:55, 3 March 2017 (UTC)
Keep Main goal of Wikivoyage is to support travelers as much as possible. Direct links to a booking service bring support not advertising. And it is the reader's decision to use this support or not. A property like booking.com hotel id means that we should have properties to other services like Ctrip and so on. Of course we cannot suppress any advertising. But Wikipedia cannot do it, too. --RolandUnger (talk) 07:55, 4 March 2017 (UTC)
Keep - if the rationale for deletion is that Wikimedians doesn't approve of the business tactics of the organisation (e.g. that it collects personal information) or that it's a commercial organisation, then I don't see how that's relevant to this Authority Control property existing on Wikidata. We have Facebook username (P2013) property for example, and other equivalently commercial organisations without any problem. Wittylama (talk) 17:31, 8 March 2017 (UTC)
Keep the fact that a website is commercial in intent is no reason not to link to it, so long as it has useful information. Provided the requirement for stable IDs is met, and there is some sort of useful information there, Wikidata can link to competing commercial websites too. The intentions of the web site owner shouldn't count, only how useful/reliable the data is (and data maintained for commercial purposes usually is reasonably reliable since it is in the commercial interests of the web site owner to keep their data current and accurate.) SJK (talk) 01:02, 12 March 2017 (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.
Keep These IDs link into a useful dataset of significant historic value, and world be worth keeping even if DMOZ goes away completely. DMOZ also looks likely to be forked and resurrected elsewhere in the near future. The Related Sites extension can also be retargeted to the new continuity DMOZ fork when it is available: what matters is the data and the community supporting it, not the hosting entity. -- The Anome (talk) 11:00, 17 March 2017 (UTC)
Keep yes, in general obsolete sites do not imply that their ID's are useless as they may have been correlated by others or may have attached data that is still available; if it had only been used a few times I might agree with deletion, but the DMOZ id has been used on over 11,000 items so I think it is definitely worth preserving. ArthurPSmith (talk) 14:34, 17 March 2017 (UTC)
Keep The DMOZ website has been shutdown but the dataset is still available. DMOZ made their data available for download as RDF and someone has mirrored the last copy here. Since the dataset still exists, even though it won't be updated and the official hosting is gone, I don't see why the property should be deleted. SJK (talk) 00:10, 18 March 2017 (UTC)
Comment: a volunteer-run static mirror now exists at http://dmoztools.net , linked to by the holding page now at dmoz.org, and thus presumably unofficially endorsed by the old site maintainers. I've now added it as third-party formatter URL (P3303) for this property. There also seems to be some low-profile activity on cresting a read-write fork. -- The Anome (talk) 07:34, 18 March 2017 (UTC)
Keep. Wikidata should record defunct identifiers used by notable organisations/projects as they are probably important for anyone learning about that organisation/project. Thryduulf (talk) 09:39, 12 April 2017 (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.
Please use existing section for this property. Do not confuse users by creating multiple discussions about the same topic. --- Jura17:29, 3 April 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 property is currently being used for (at least) three separate things, which I think is a bad idea because Wikidata is about structured data and storing comments as data only makes sense if the properties are well defined (i.e. we know what the comments are for, who they're aimed at and when they should be shown).
This property was originally added to store comments for property constraints and was not intended to be used just yet. Unfortunately, the original label and description were too vague. The description was then changed, which redefined the property and turned it a property for usage instructions instead (see also phab:T97566). The label is still vague, so it's also being used as a generic comment property whenever people want to add a comment to something (some of the ones I've seen appear to be people wanting to add custom edit summaries, which is covered by phab:T47224).
I'm proposing to delete this property as it is currently poorly defined and none of the uses are what it was actually created for. Instead, I suggest that we add a new property to replace the original approved property (with a better label and description, "Wikidata property constraint comment" might work) and create two new property proposals for the other uses. If the new proposals are accepted, the existing statements for this property should be migrated to the new properties. If they are rejected and this deletion request is accepted, the existing statements should be deleted.
Comment I cleaned up the most of the remaining uses. Going forward, usage instructions that are in descriptions, can use Wikidata usage instructions (P2559). Once the MediaWiki feature is available, this can be removed from descriptions. Notes that are in qualifiers, can continue to use this property. Obviously, it needs to be monitored to avoid that it isn't misused. To limit this, I changed the property label (the problem with the current label was already pointed out before it was actually created). Currently the bulk of inappropriate uses were those that should have been using P2559, but weren't converted when that property was requested and created. Seems like someone didn't follow up on the creation → fixed. There were a few cases liked this, where actual content was added in the property. It seems the property now works as it should. --- Jura11:27, 25 March 2016 (UTC)
Please don't change labels of properties in substantive fashion while there is an ongoing deletion request. I should have but didn't realize that the edits I made earlier today were to this property. --Izno (talk) 12:12, 28 March 2016 (UTC)
Sorry about that, I thought I had cleared up the problematic uses and the only remaining ones are the ones where this covers a gap between the new property and the remaining uses. To avoid future problems, the label needs to be changed (as already suggested before creation, on first discussion, etc.). If there are no arguments against it, we can finish sorting this out and can close this discussion. --- Jura10:20, 16 April 2016 (UTC)
Comment @Lymantria: thanks for cleaning up the unstructured uses of this property, but could you do a plan for the remaining uses? Just deleting it when it's still in use isn't a good idea. Generally, we identify alternatives, then remove the the property, and, at last delete it. --- Jura13:02, 2 June 2016 (UTC)
I don't see what you mean. Wikidata usage instructions (P2559) is instsalled to reflect the original scope of the property plus its first extension, while a property on comment, the unstructured data, was rejected. I am not aware of any other initiative to split parts off the original property. I removed all usage that IMHO shouldn't be there or could be replaced. Nothing left, so deletion was in my view the thing to do. Lymantria (talk) 13:12, 2 June 2016 (UTC)
There are about 222 uses left mainly by Laddo which don't fit P2559 nor the other proposed property. Probably some of the people commenting above made the same error as you did. --- Jura13:17, 2 June 2016 (UTC)
@Laddo: Propose a new property. I am skeptical that it would be declined. If it is declined, there is still the talk page for this information. --Izno (talk) 15:23, 2 June 2016 (UTC)
Thanks, Most of the items concern comments on errors in sources. I am thinking of proposing a property on that. Lymantria (talk) 05:18, 24 June 2016 (UTC)
Keep It's useful to have a way to document why a certain decision is made. If I read a biography and the it gives me an occuption of a person but there are two different ways I could model that occuption in Wikidata it's good to be able to leave a comment to explain why I chose A and not B. ChristianKl (talk) 19:44, 20 July 2016 (UTC)
Delete - Even if in some cases can be useful for editors, it's too tempting for introducing unstructured data, which is totally useless for users. So should be removed, editor comments can always be written in the talk page. —surueña11:21, 17 August 2016 (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 Are you looking at the same property? It's been used 4500+ times. It was proposed for deletion 3 years ago and decided not to - see discussion here. Yes there are more specific properties that should be used if they apply, but this one is suitable for generic use with a qualifier indicating what system the code is for, I seem no reason to delete. ArthurPSmith (talk) 13:32, 22 December 2016 (UTC)
I'm torn. The fact that MTR station code (P1377) and China railway TMIS station code (P1378) etc exist means that this is somewhat redundant if we insist on having the mandatory qualifier. On the other hand, if we remove the mandatory qualifier constraint, this property can be used more liberally with various transport systems. Other properties of the station item can be used to tell us which transport system it's in. On balance I vote deprecate andDelete. Deryck Chan (talk) 18:10, 10 March 2017 (UTC)
I'll be willing to change to keep if we relax the \w+ format requirement so that the Japanese and Norwegian uses of this property - which are the vast majority of uses not already covered by more specific properties - cease to be constraint violations. Deryck Chan (talk) 15:24, 22 March 2017 (UTC)
Same, but there should finally be some decision on whether this should be done, or the more specific properties migrated to this one. --Nenntmichruhigip (talk) 13:32, 18 April 2017 (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.
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.
"Specifically"? Really? No will find it, nor know how to use it. Too ugly for general users. So Keep as this named and used property is useful and user friendly. Far better to fix up the relationships of what exists rather than try to recreate what looks like a working wheel. — billinghurstsDrewth
Delete, but keep P794 (P794). I actually want the latter to have an even broader use than what it has now. It is precisely the fact that it catches everything that makes it useful and easy to use. Thierry Caro (talk) 13:27, 14 February 2017 (UTC)
"Object has role" is no better and lacks clarity. I doubt that anyone is going to think of some other person as an "object", nor that a relationship of grandparent, or father-in-law as a "role". They are people and have relationships/kinships/... — billinghurstsDrewth23:53, 19 February 2017 (UTC)
Comment I would like to reduce number of basic properties to memorize: SPARQL/easier data entry, but I also understand comments about "Object has role". d1g (talk) 09:25, 3 March 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.
Keep With P:548, we know the value type of this qualifier (Q28530564); with the "global" property "object has role", we can't set this constraint and this property will be less well defined for this specific use than P:548 (notifying WikiProject Informatics has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. because this property is about software version type). — Metamorforme42 (talk) 17:40, 2 March 2017 (UTC)
Keep Specific properties are easier to use than a generic qualifier. The generic qualifier can't have constraints specific to this domain on it as Metamorforme42 points out. (Or, if there was some way to conditionally apply them to the generic qualifier, I think that would get very unwieldy quickly if generic qualifiers have dozen of domain-specific conditional constraints on them.) SJK (talk) 01:14, 12 March 2017 (UTC)
Keep For the time being the specific property has big usability benefits as pointed out before while the disadvantages are marginal. ---- (talk) 16:04, 24 March 2017 (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.
Keep per Kumkum. It's very important that we don't combine properties that record a POV with those that record statement of fact. Thryduulf (talk) 09:36, 12 April 2017 (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.
Your reading powers are awesome, "selectively canvassed" is indeed what I wrote. Now please apply those powers to the proposal I made at the start of this section. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits23:18, 15 May 2017 (UTC)
So what is „rendered redundant“ by the creation of this new property? Please be more talkative, Mr. Mabbett. Thanks. --Succu (talk) 20:16, 17 May 2017 (UTC)
I would prefer that taxonomy would also use the qualifier solution with named by (P3938) but I see no reason to delete this existing property as long as the data isn't moved over. ChristianKl (talk) 10:13, 23 May 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.
Keep Not the same thing at all. A catalogue code is a specific code signed to an object when it appears in an exhibition. An inventory number is a number assigned by the institution where the object resides. They are two totally different things (and this is what I spent $80k getting into debt to learn... ;-) Missvain (talk) 20:44, 15 May 2017 (UTC)
That distinction does not appear to be made on Wikidata. Not least since galaxies and other astronomical bodies, for example, are rarely exhibited, nor kept in institutions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits21:21, 15 May 2017 (UTC)
Sounds like galaxies should not be using inventory numbers then and just catalogs. When it comes to paintings or other movable heritage, however, we need both. Jane023 (talk) 22:01, 15 May 2017 (UTC)
Because a painting can be lent out for an exhibition, whereupon its exhibition catalog number is not the same as its inventory number in the lending institution. They are two disctinct concepts that should not be confused. An inventory number refers to a collection, while a catalog number generally refers to a page in a printed book. Jane023 (talk) 15:56, 16 May 2017 (UTC)
The fact that "a painting can be lent out for an exhibition" in no way precludes the combining of these two properties. Nor does the fact that some catalogues exist on dead tree media. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits18:44, 16 May 2017 (UTC)
There are very few museums that have kept their numbering consistently for longer than two decades, besides some fossilized 19th-century royal collections and other slowly-changing collections. There are many many inventory numbers that have thus never been printed in an official catalog with their inventory numbers at the point in time they had that inventory number. This is generally information only kept at the institution itself. It would be detrimental to the project to remove this needed identifier for collections. As far as merging the identifier with the collection property, I am also against this, as most collections do not have identifiers (private families, small collections, etc). Jane023 (talk) 08:27, 17 May 2017 (UTC)
"It would be detrimental to the project to remove this needed identifier for collections" is simply a rephrasing of "we need both"; not an argument as to why both are needed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits22:27, 17 May 2017 (UTC)
To track paintings in collections on Wikidata, whenever possible, we like to use inventory numbers of institutions, because we can easily cross-reference these with other publications and online resources. The visual image and measurements are not enough to determine the uniqueness of a painting and other characteristics are needed. The inventory number is just one piece of the puzzle. Catalogs of works in an institution may or may not be published by institutions themselves, but are also an important piece of the puzzle. Art auction data is also important; in that case, a painting may be assigned a lot number and this is often used in art provenance records in combination with the date, place, and name of the auction house, whether or not that specific painting made it into the printed sale catalog (if a sale catalog was even printed at all). At a following auction, the same lot number can be re-used, so to refer to a specific painting in any auction you need the number in combination with the other references. The exact same thing is true for collections, except the accessioning and deaccessioning process happens a lot more slowly. Catalogs, on the other hand, are assembled at the discretion of the author, and sometimes the author is well versed in provenance methodology, and sometimes not. So a catalog might be recorded by number, number + page number, catalog number, footnote number or illustration number in addition to catalog number, etc. So the idea of using an inventory number for a collection is a lot cleaner than using a catalog number, which can be quite messy. Museums produce catalogs regularly for exhibitions, and from time to time they may produce highlight catalogs (which sometimes do and sometimes don't include the inventory numbers). They very rarely produce catalogs on paper of the entire collection. Probably less often than once every 15 years or so. Merging these fields would making tracking much more difficult, in addition to confusing the number assigned to a painting by an institution in its inventory and the number assigned to a painting by the institution in one of its printed catalogs. Jane023 (talk) 12:11, 18 May 2017 (UTC)
Keep I first ran into catalogue code and inventory number in connection with paintings. To me the inventory number is special from a catalogue code in that it entails an ownership and it is the owner that makes the inventory number and there is usually only one. Catalogues may be made by anyone and every exhibition or "reasoned catalogue" (catalogue raisonné (Q1050259)) may have there own numbering scheme. For most painting we would expected that there is always an inventory number. There may be zero or more catalogue numbers. I also concur with the arguments of Jane023. collection (P195) and catalog (P972) to me are also distinct. — Finn Årup Nielsen (fnielsen) (talk) 18:14, 29 May 2017 (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 per the nominator--these should be replaced since a wins/losses combined property is non-granular semantic information (indicated by the expected dash). --Izno (talk) 13:59, 8 March 2016 (UTC)
Keep for now. Four properties make more sense, but this property should be kept until then. Qualifiers are not an appropriate substitute for sub-properties, though. --Srittau (talk) 02:45, 25 March 2016 (UTC)
"but this property should be kept until then" - We have the replacement properties and just need to do the replacement. Voting keep based on the fact it's being used is not a valid reason for keeping. Lastly, sub-properties are a bad thing. --Izno (talk) 12:14, 28 March 2016 (UTC)
@Izno: In your proposal, how should we then call-up the replacer for "win-loss balance in singles" in infoboxes (currently called-up as {{#property:P564}})? I have no clue as to how the code would look like that I would have to write in a tennis player's infobox. Vinkje83 (talk) 10:37, 5 July 2016 (UTC)
Keep These two properties are actively used on quite some languages, in tennis-infoboxes. Deletion will make it a lot more difficult to maintain the value of these items (that is changing basically every week for active players), as well as replacing those properties in the infoboxes. For tennis, this is just the way statistics are registered, and this is the only way this makes sense for tennis. For other sports, these properties should not be used. Maybe the name of the properties (or their explanation) should be changed to clarify that they are tennis only? Edoderoo (talk) 21:37, 2 July 2016 (UTC)
Keep The concept of 'win/loss balance' is a natural phenomenon in tennis. A concept like 'number of matches won' in itself has no meaning there (neither has 'number of matches lost'). It's only the two numbers together that make sense. The inclusion of singles record (P564) and doubles record (P555) in tennis players' infoboxes is finally coming into use (more than just occasionally), and their wikidata values are actually getting updated by the international community. Replacing them by four new properties (two would not work, obviously) would cause more complicated code to include them in the infoboxes, and that will most probably arouse new objections against wikidata. Vinkje83 (talk) 23:31, 2 July 2016 (UTC)
Unfortunately LUA is not (yet) accepted on some wiki's, like nl-wiki. Use of WikiData-data is actually not fully accepted yet, though "we" try to push it through in some areas where it makes most sense, like these two highly changing properties (updated weekly, in theory). But in theory LUA would indeed take away some of the issues, but for the moment I would prefer to keep these two properties, as without them some wiki's will simply loose the data completely right now. Edoderoo (talk) 19:43, 27 August 2016 (UTC)
Client decisions not to use Lua (really??) shouldn't affect our decisions. That's just, frankly, dumb. While they're welcome to their opinion, they're also welcome to the consequences of that opinion, and one of them is that they may not have access to the same power as other wikis do. --Izno (talk) 19:49, 27 August 2016 (UTC)
And we wouldn't delete number of wins (P1355) and number of losses (P1356), when converting data. At least, I was planning to do that. Once I would convert everything (keeping also old props), then is the work with Wikipedias. We can also have some logic in module - if there isn't the "new" properties, load the "old" ones. Yes, we would have extra work in maintaining data for some while, but with help of SPARQL queries that is pretty easily doable with python. --Edgars2007 (talk) 20:31, 27 August 2016 (UTC)
There is no official vote or something that lua shouldn't be used on nlwiki. Edoderoo is probably talking about nl:Module:Cycling race and the relevant discussion. It's not weird that a part of the community doesn't like pushing of "outsiders". Sjoerd de Bruin(talk)12:10, 6 September 2016 (UTC)
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 link to annoncment in ruwiki, lvwiki, itwiki, arwiki. Eran (talk) 12:23, 9 September 2016 (UTC)
Keep Per Vinkje83 and Edoderoo, these properties are widely used in tennis infoboxes in this combination (win/loss).--Wolbo (talk) 01:31, 22 February 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.
Keep "docking port" is more equivalent to the particular gate at a terminal that an aircraft uses, and I don't think you would ever assign that using 'via'. If there's another analogous property then I wouldn't object to merging, but I don't see these two as being anywhere close to equivalent. ArthurPSmith (talk) 14:39, 4 August 2016 (UTC)
Delete but I prefer not to use via (P2825) but instead significant event (P793). A spaceflight has many key events, and it's excessive to create for each possible event a new property. On Q591584#P793 I demonstrated a while ago how this could work. Soyuz TMA-9 (Q591584) had two docking ports. With the current approach you don't know which port was served first and during which time they were served. Because there are a handful more properties describing key events of the spaceflight, it's in addition hard to extract a timeline of the flight. With significant event (P793) we gain a better overview and can model the whole journey. --Pasleim (talk) 15:58, 4 August 2016 (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.
Comment if the links aren't working any more, you can set the formatter URL to "deprecated rank". --- Jura14:14, 13 December 2016 (UTC)
Delete as per nomination. Having an identifier that points into a database that is no longer available is of questionable value. 50.53.1.3322:19, 9 February 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.
When the external-id datatype was introduced, we had long discussions about which properties should have external-id datatype. Consensus was somehow that an external-id should uniquely identify a concept, that's why certain string-properties weren't converted to external-id, e.g. hashtag (P2572). For me Quora topic ID (P3417) is pretty similar to hashtag (P2572) as it was introduced to group together posts and ease searching. They don't identify concepts but group together ideas like Exams and Career Advice, Tips and Hacks, Concrete and Cement. Therefore I Support to move this property from external-id to string datatype. --Pasleim (talk) 10:59, 26 December 2016 (UTC)
Mis-application of a topic by a tiny number of individuals (there were just three for popcorn, out of 204 questions) does not invalidate the correct usage. This is no different to Wikipedia or Wikimedia Commons categories, for example, or other external IDs. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits17:58, 26 December 2016 (UTC)
I'm not clear whether Succu's reason for wanting to overturn the consensus that saw this property created is that 701 people (Too many? Too few?) follow a single specific topic; or that it was me who made the valid match between that single topic and the equivalent item in Wikidata. Which is it? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits10:29, 27 December 2016 (UTC)
For me it isn't clear: this proposal is for delete the property, or for delete this property and recreate it with a different data type? --ValterVB (talk) 18:02, 27 December 2016 (UTC)
It's to delete it and recreate it with string datatype. We can only do the opposite change without deleting. For the full deletion of the property, a second section would need to be started. --- Jura18:36, 27 December 2016 (UTC)
Support conversion to string datatype. In addition the problem that came up on Project Chat which prompted me to start this thread, there seems to be also a stability issue with these strings. As the explanations we get to the contrary are comments like "ridicule" and acts conver up instead of explain possible issues that come up, these links seem highly problematic. --- Jura15:01, 31 December 2016 (UTC)
Yet again, I need to remind you that adding "support" to your own proposal is double !voting. Your nomination was described as "ridiculous", which is not "ridicule". No evidence of a "cover up" has been shown. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits22:26, 31 December 2016 (UTC)
Keep Since string and external-id have the same structure this should not be "delete"; so the real question is whether a conversion is merited. If I am understanding the original external-id conversion arguments, I believe this should be external-id over string. The differentiating factor seems to be whether the value has peer review (Q215028) as a unique controlled vocabulary (Q1469824). Virtually all identifiers are used for grouping (e.g., all of authority file (Q36524) and document indexing (Q1167863)). Though hashtag (P2572) is certainly used for grouping it is not a peer reviewed controlled vocabulary (so it is very easy to come up with different hash tags that essentially cover the same concept). This is why I see it differently than this one. 50.53.1.3322:07, 9 February 2017 (UTC)
Keep with external ID. If someone finds it useful, and it's not causing any direct harm to our project, then by all means let it be. Icebob99 (talk) 15:50, 5 March 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.
@Pigsonthewing, YULdigitalpreservation, ChristianKl: At the moment this property works only for species (formatter: href=/cgi-bin/NSWfl.pl?page=nswfl&lvl=sp&name=), but the website has
families (href=/cgi-bin/NSWfl.pl?page=nswfl&lvl=fm&name=, e.g. Acanthaceae
genera (href=/cgi-bin/NSWfl.pl?page=nswfl&lvl=gn&name=, e.g. Avicennia
I am not a big fan of URL's in Wikidata (unwieldy), and actually I would be in favour of switching GRIN from URL to external identifier (should be quite doable). Having said that, this particular case is a very poor candidate for an external identifier, as it apparently would lead to "in&name=Avicennia~marina+subsp.~australasica" as a external identifier, which is just as unwieldy as a full URL. - Brya (talk) 10:49, 30 September 2016 (UTC)
My unease consists of two points: 1) if one checks an item the URL's are in a place where one does not expect them (GRIN is in a different block from GBIF, ITIS and other such databases). 2) readability of a URL is very poor (too long). - Brya (talk) 19:28, 30 September 2016 (UTC)
Thanks. So both of your concerns are about the handling by the Wikidata UI I think. The migration to external ID resulting into the rendering it in a separated section has a lot of pro and cons but was leaving the datatype URL behind. I'd like to see them united. I'm not sure how this could be done, but I'am sure that declaring fragments of an URL as an external ID is the wrong way. --Succu (talk) 20:19, 30 September 2016 (UTC)
P:P2549 having indeed a combination of two parts in the ID. I don't see much objection in using something similar here for the identifier, hence having "lvl=fm&name=Acanthaceae" as the identifier, which indeed is the identifying part.
My point is that I disagree with you that lvl=in&name=Avicennia~marina+subsp.~australasica cannot be considered an identifier. The actual fact that the identifier is made part of a URL is hardly an argument. Lymantria (talk) 19:49, 4 October 2016 (UTC)
Nope. And that is neither what I said, nor what I meant. But the ID has become part of the URL. Do you suggest that the part does not identify the database entry uniquely? Lymantria (talk) 20:14, 4 October 2016 (UTC)
You seem to state that you want to delete Property:P3035 and Property:P3097? That would take a new deletion request. But what you say about the general case, would mean that ID's with a formatter URL cannot be ID's, because the URL is already an ID. I fail to understand that. Lymantria (talk) 05:33, 5 October 2016 (UTC)
But then, the actual problem is that - just like International Standard Book Number (Q33057) - its identifier consists of two parts, one describing "lvl" (somewhat similar to "level"), and one pointing to the actual taxon. There is even a third, "page=nswfl" pointing to the database. The mere fact that the UI does not allow multiple part entries for ID's does IMHO not disqualify these to be identifiers, combined into a single identifier.
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 do not object to deleting, or keeping. However, I would like to understand why the standard was withdrawn - the ISO language codes are certainly useful for a lot of what we do here, is there a plan to replace it with something else? ArthurPSmith (talk) 19:00, 13 December 2016 (UTC)
@ArthurPSmith: Its current status is "withdrawn, no replacement", but of course ISO 639-3 and others remain operational. I haven't found the official reasons behind the withdrawal, however on this paper they shed some light on the inconvenience of using language codes for language classification and the lack of consensus on the topic, as language are fuzzy living entities and it is quite hard to find boundaries, even more so for variants. On this email on the ietf-languages mailing list hint towards a lack of usefulness, plus that the agency that was designated as registration authority ceased its operation.--Micru (talk) 08:22, 14 December 2016 (UTC)
Keep While I have doubts about how useful or verifiable the data is, several Wikipedias include this in their infoboxes and some are even using the data from this property. - Nikki (talk) 17:13, 27 December 2016 (UTC)
Delete as per nomination. With the specification withdrawn and the data no longer available this seems to be of little usefulness. There are several other ISO 639 identifiers that can be used in lieu of this one. 50.53.1.3322:16, 9 February 2017 (UTC)
Keep Given that Wikipedia import the data into their infoboxes. We should delete data that get's used in infoboxes without good reason. ChristianKl (talk) 11:18, 11 February 2017 (UTC)
@Liuxinyu970226: Whether the individual Wikipedias want to delete the paramater from their infobox is an editorial decision on their side and not something that a Wikidata approved bot can decide.
Keep as in use. Yes a bot could delete the parameters from the infoboxes, but then that would result in the data currently present in the article disappearing - if we want Wikipedias to use Wikidata as a source for infobox information it is very important that we don't delete the information they are using without their consensus. Separately I don't see why Wikidata has to restrict itself to currently used identifiers, surely our mission includes representing the world as it was rather than just as it is (otherwise why have entries for entities like German Democratic Republic (Q16957) or properties like end time (P582) instead of deleting the no-longer valid data). Thryduulf (talk) 09:27, 12 April 2017 (UTC)
Question according to Wikipedia this has been withdrawn, but was it replaced with anything? If a newer, better standard exists then we should replace this identifier with the newer version, and Wikipedia infoboxes should follow suit. Laurdecltalk06:08, 15 May 2017 (UTC)
Keep as useful and meaningful
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.
Oppose Using a specific property as opposed to a generic property with a qualifier is more user-friendly. It is less clicking/typing, easier for new users to understand, etc. I think qualified generic properties should only be used if no specific property exists, and specific properties should only be deleted if they are useless (and 851 uses proves this isn't useless.) SJK (talk) 00:57, 12 March 2017 (UTC)
Delete "number of ..." (lifts) belong to units. I see "lits" as units. One property or qualifier is enough to describe "totals". I don't understand why do we enter units, when we can explode property count for every unit. Do we need units or do we need specific properties instead of units? d1g (talk) 15:13, 30 April 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.
IDEAS is a particular site based on RePEc`s data. Since the identifiers are the same, it is bad to keep both in Wikidata, because data entry efforts split up between the two, and it would be cumbersome trying to keep them in sync. RePEc Author links are meant to be permanent (see the note on the bottom of, e.g., https://authors.repec.org/pro/pal207/), whereas IDEAS URLs don't claim that. -- That said, the IDEAS page contains more information (about ranking, download statistics and so on), so there is value in linking to it. Is there something like computed fields in Wikidata, which would allow us to offer only P2428 for input, but to display an additional computed link link to IDEAS? Jneubert (talk) 13:56, 12 May 2017 (UTC)
As of just now, there are 14 items which have P3649 and no P2428, while 1787 items have P2828 and no P3549. Jneubert (talk) 14:14, 12 May 2017 (UTC)
From time to time I check for P3649 and update P2428, if not present. So as of just now, there are no such items. Jneubert (talk) 16:51, 11 July 2017 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Please, delete one of them... I prefer Q22051121 to be deleted, because it haa no link at all. But before deletion, please transfer all usefull data what missed from the other...
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.
Keep I'll concede that this split model doesn't work particularly well with the given tunnel example. However, it is the best solution for road items, for reasons spelled out in the property proposal linked above. -happy521418:34, 25 April 2017 (UTC)
Delete I think it would be helpful to have P276 qualifier in P559 - we have to use direction qualifier anyway. P609 is specific but adds no new information over P559 and P276. And we need to qualify P609 anyway using same qualifiers. d1g (talk) 05:47, 10 August 2017 (UTC)
It seems apparent that the problem here is that the railways community and the highways community use terminus (P559) differently:
Highways: terminus (P559) for connections to other highways at end of a highway; terminus location (P609) for the wider geographical area where the end of the highway is located
Railways: terminus (P559) for the station / depot / feature which marks the end of the railway line.
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 with modified formatter URL for those photographers where the pages were archived at archive.org, at least until the same information from that archived page is actually also available elsewhere. The fotografen.nl had some quite valuable information that was (and still is) not available on the RKDartists website (sample photos by the photographer, a bibliography, sometimes a short written biography and information about memberships and management of copyrights). And it turns out that the Wayback Machine has partly archived fotografen.nl. I therefore suggest to keep the property and change the formatter URL to
Comment The 'web-beta.archive.org' URL at Internet Archive gives better results than the 'web.archive.org' version.
Comment A quick test seems to show that this only works for some photographers whose oeuvres are managed by the Nederlands Fotomuseum. I'm willing to inventorize their list and remove the values for those statements that don't link to working archive.org pages. Spinster💬 17:17, 15 April 2017 (UTC)
Comment We have archive URL (P1065) for linking to archived pages. If the outcome is to keep the property, I think adding qualifiers for known archived pages would be better than changing the formatter URL. - Nikki (talk) 17:37, 9 August 2017 (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.
The original proposer has already been contacted about this. Personally, I would like Wikidata to support auto-derivative properties at its technical level; however, as this feature is still not available, editors have been avoiding this kind of (duplicate) properties until now. --abián21:17, 22 July 2017 (UTC)
Comment The problem with third-party formatter URL (P3303) is that most of the time the third party does not use all the identifiers available in the first database and we have no way to know this before we actually click on the link and discover this very one is not covered. With this in mind, I've come to believe that third-party formatter URL (P3303) in its current form is a bad thing, and that we should have a standalone property every time the formatter URL varies, even when most of the IDs it points to are shared. Thierry Caro (talk) 00:59, 7 August 2017 (UTC)
But "catalog (P972)->-BVMC PLACE "CATALOG" ITEM" would be kind of a reach, so P972's scope would need somehow to be expanded.. And after we wouldn't even have a "click-able link" here.
Anyway, if we are gonna have these properties, a specific constraint like «if P4098 exists, then its value has to be equal to P1566's»... would be nice. Strakhov (talk) 17:56, 9 August 2017 (UTC)
I don't think it can be done with normal constraints right now, but it would be easy to do with a complex constraint, using something like this query. - Nikki (talk) 10:21, 25 August 2017 (UTC)
Note that, in this case, the issue exposed by Thierry Caro doesn't apply. The BVMC lets you use any identifier available in Geonames (example, example) and retrieves the information on the fly. However, all your comments are being very enriching, thank you! --abián18:27, 2 September 2017 (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.
@Ayack: By "the meaning of the statement" are you asking local field names? If yes, those can be locally modified, no needed to absolutely use Property names. --Liuxinyu970226 (talk) 15:25, 25 July 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.
Keep Of course, the content of OSM relations can be changed, the content of Wikidata items too. Delete Wikidata! No, don't do that. Be aware things can bechanged and deal with it. Many important OSM objects are monitored and maintained. As an OSM contributor I have a look at many objects and find them in good condition, stable enough for Wikidata. --Quarz (talk) 16:15, 1 October 2017 (UTC)
Keep Very useful. I don't have seen any changes in my workspace from OSM so where this "figures" comming from. About how many % we're talking from? --Derzno (talk) 17:11, 1 October 2017 (UTC)
Comment The correct way to do OSM would be linking to the tags and not to the id and in this case it would be the Wikidata tag (OSM permanent id). However the problem that needs to be solved before P402 can be deprecated is how to check in template/Lua if the wikidata tag exists. Currently this is not possible and without any external information stored in WD it prevents autozooming to the area in mapframes and automatic linking to the correct OSM relation. Until this happens one solution is to sync OSM wikidata tag values and P402 values with a bot like Mateusz Konieczny considered and I wrote my take on this: Wikidata:Mapframe-autozoomZache (talk) 05:39, 2 October 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.
Keep Jura's unanswered question was whether the ID's were stable; it certainly would have been nice to have an answer. Perhaps @ChristianKl: would like to comment on why he ignored the question in closing this? Nevertheless I think this is a useful property (and as far as I can tell the ID"s are stable). ArthurPSmith (talk) 16:07, 12 October 2017 (UTC)
Keep Useful property for company disambiguation, and as a source for insights upon it. The process to change an ID is complicated (you have to manually file a request to LinkedIn), making the property rather stable. Teolemon (talk) 14:35, 14 October 2017 (UTC)
At this stage, I think we only need to discuss if the closure was premature or not. If yes, the property can be deleted. --- Jura06:10, 16 October 2017 (UTC)
Most administrators and property creators try to follow the applicable process. I noticed that ChristianKl mostly ignores it, but this isn't a reason to let these slip through. It can be created later, once everything is sorted out. -- --- Jura20:26, 18 October 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.
Consensus to keep, given that it's not in quality different than storing Facebook username (P2013) and similar identifiers. The property is not to be used to reveal the identity of users who didn't disclose their identity publically and doing so would be subject to sanctions as explained in the usage instructions of the property. ChristianKl (talk) 17:28, 4 November 2017 (UTC))
Keep. But delete the warning message. There is no reason to have for Wikimedia a special policy that we don't have for Facebook or Instagram. Thierry Caro (talk) 13:41, 25 August 2017 (UTC)
Neutral this property shouldn't have been created until a consensus had been reached on how to use it but now that is has been created, I see no real reason to delete it. PS: I have no illusion, the property is not really the issue here, with or without this property, the exact same data can, were and will be stored (prior to this property creation there was already a hundred of wikimedia user name store in various ways). Cdlt, VIGNERON (talk) 13:44, 25 August 2017 (UTC)
Keep per my arguments made in the creation conversation — not least that the information is already held; at least this way it can be monitored more sensibly. — OwenBlacker (talk)13:56, 25 August 2017 (UTC)
Keep. Arguments of Thierry Caro are right: there is no difference between a Wikimedia username and an other username in an other website (for example Twitter, where a lot of people also use a pseudonym). Tubezlob (🙋) 15:18, 25 August 2017 (UTC)
Are you saying that you wont be respecting WMF policies even in fields where it's applicable? --- Jura15:34, 25 August 2017 (UTC)
oh yes, there is an enormous difference - on Facebook, you have to use your real name (per FB rules) ; there is NO privacy of FB, per FB rules - on wikimedia, there is an officialPrivacy policy !! - it is totally different --Hsarrazin (talk) 22:50, 25 August 2017 (UTC)
Delete useless with current "usage instructions". Encouraging users to create items about themselves is not a good idea.--Jklamo (talk) 21:05, 25 August 2017 (UTC)
After this is deleted, I don't think it should be stored with that property. Already now, some seem to have used that other property as a way to circumvent as creation of this property was refused due to privacy concerns before. --- Jura10:52, 26 August 2017 (UTC)
Keep As every properties, this one is intended for public and referenced information. If it used differently, we have a policy for the disclosure of non-public personal information (with oversighters to remove such data and administrators to ban transgressors). As noticed by VIGNERON, this property allows to store Wikimedia usernames in a single place, making possible to monitor and detect bad usage much more easily than the actual situation. I also agree with Tubezlob: Wikimedia usernames don't differ from Twitter (X) username (P2002) or Instagram username (P2003), and I see no one stating that they were created to doxx Twitter and Instagram users... -- Envlh (talk) 21:33, 25 August 2017 (UTC)
Keep per many of the above. Furthermore, this property passed a property proposal in the last few days. PfD should not be used to circumvent that process; the claim of "lack of consensus " is false. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits09:43, 26 August 2017 (UTC)
That it passed a property proposal is an undisputable truth. The claims that it should not have done so are far from "strong", and have no merit. They're made by the original objectors, who aren't happy at being in the losing minority - but the proposal was closed by a neutral admin. Even if the admin was at fault, then the avenue for remedy would be the Admin Noticeboard (or Project Chat), not PfD. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits13:36, 26 August 2017 (UTC)
Keep - the arguments on the property proposal page against this were unconvincing, as the concerns could be solved with policy and simple queries to keep things in check. We should not be outright deleting a property because it might be a problem, when the utility is clearly demonstrated. -- Fuzheado (talk) 13:48, 26 August 2017 (UTC)
wrt to this thing being the same as twitter or facebook or instagram, it is an undisputable truth in those social networks users can protect their accounts with a lock, not allowing common people to scrutinize their actions, pictures or vapid fantasies. In Wikimedia projects all your contributions are open, with the exact time you saved them, every topic, every comment in every discussion. We even offer tools to stalk user's edits. And it's not possible to hide any of that under a little tiny lock. It's not even possible to delete your account here. It's not exactly the same. Strakhov (talk) 23:38, 26 August 2017 (UTC)
thanks Strakhov, this is exactly the problem : this makes too easy scrutinizing edits of a user, by persons who, without this property, would not be able to link the username to the real-life identity… only voluntary disclosure by concerned users should be allowed to avoid risks for contributors in their private and/or professional life --Hsarrazin (talk) 17:14, 28 August 2017 (UTC)
keep as any personal identifier it makes no sense to allow home page, but prohibit social media accounts (incl this). Personal web pages are not replacement to other accounts (e.g. youtube cannot replace homepage and vice versa).
We could improve any description in order to follow any policy - it is strange to remove property. d1g (talk) 04:20, 27 August 2017 (UTC)
Comment many lawbreaking things could be entered in Help:Description - should we remove them?.. Please don't make this slippery slope argument every time. This is not specific to properties or even specific property. d1g (talk) 04:37, 27 August 2017 (UTC)
Delete until issues on "only the account owner is able to..." are resolved. We are not in a hurry, since people willing to disclose their Wikimedia alias already discovered how to store this data circumventing previous refusal and, after all, there are not so many legitimate uses. Strakhov (talk) 11:12, 27 August 2017 (UTC)
By the way, our labour here is about constructing a collaborative database, not losing or winning proposals. Strakhov (talk) 11:19, 27 August 2017 (UTC)
Comment First, I'd like to see a comment from WMF's legal staff or quotation of privacy policy that states that this property should not exist. Second, this property had actually existed as website account on (P553)/website username or ID (P554) before this one was created, so in my opinion there didn't have to be any discussion about its existence. Matěj Suchánek (talk) 16:47, 27 August 2017 (UTC)
Maggie and I have talked (and consulted with legal) and while we don't believe it is a violation of the Privacy Policy (and so wouldn't try to block it etc) we do note that it does have the potential of being used for harassment or outing (in violation of the Terms of Use) if done without the blessing of the user involved and/or when it isn't pubic knowledge. There are lots of users who are very public with the fact that they are the same person who an article is about (hence the existence of well used talk page templates or user boxes) but it can also be a problematic thing if they're trying to preserve their privacy online like many of us try to do. Jalexander-WMF (talk) 22:47, 29 August 2017 (UTC)
Keep: I'm for keeping it, but to use it only when a profile page on any Wikimedia project already discloses this information. This profile page should then be added as reference URL. -- Maxlath (talk) 15:06, 28 August 2017 (UTC)
Keep if a bot can actively revert all changes involving this property by non-autoconfirmed users (on the assumption that all autoconfirmed users are aware of and adhere to the WMF's privacy policy). Mahir256 (talk) 16:15, 28 August 2017 (UTC)
Keep Wikidata has many properties for things that count as sensitive personal data: birth date, gender, sexual orientation, union membership and online account are examples. A breach of privacy comes when people use these inappropriately, adding speculative or inappropriately obtained data. The fact that Wikidata can represent such data is not the fault. Hence it is a fallacy to argue against the existence of the property on grounds of possible misuse. None of the arguments for removal seem solid. MartinPoulter (talk) 14:07, 29 August 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 new property replaces content that is actively used in Reasonator. There is no real benefit compared with the use of "is a list of"--GerardM (talk) 21:22, 30 September 2017 (UTC)
Comment It is an in-crowd that is involves in property proposals. When their work cannot be objected to it means that their work is to be considered infallible. This argument expresses a superiority that is not warranted. There is damage so I ask for a speedy deletion. Thanks, GerardM (talk) 06:04, 1 October 2017 (UTC)
as opposed to this case with the new property? I agree with folks above, we should urge Magnus to support this in Reasonator. Maybe the migration to the new property should wait until that's done. I don't see this as a reason to delete the property though - it's simply wrong to say that a category "is a list" of something, categories are not organized that way. ArthurPSmith (talk) 15:13, 1 October 2017 (UTC)
Humour me and explain why it is not a list. The fact that this list is part of a category is already in the type of the P31. It does not need further refinement imho. Thanks, GerardM (talk) 06:00, 4 October 2017 (UTC)
In both instances the content of the list at Wikidata is the same. It has little to do with what is actually in an English list or category as it is a combination of what is in German, Russian, Dutch etc categories and lists as well. Thanks, GerardM (talk) 14:45, 4 October 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.
My apologies. I proposed the duplicated property unaware of the old one. They should be merged as much as that is feasible. ~★ nmaiad01:06, 30 October 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.
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.
@Pamputt: Well, my comment above in theory shouldn't be a reason to withdraw this pfd, since I still don't see how an example could be happened, really the 4sq staffs should consider a better way to search *public* user details. --Liuxinyu970226 (talk) 05:50, 18 September 2017 (UTC)
Comment I don't doubt the validity of this property, but I doubt its usefulness. In what situation will this be useful for curating public knowledge? Deryck Chan (talk) 09:24, 22 September 2017 (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 as I believe this should simplify things a little. However, there are hundreds of P2656 entries now, so first they should be migrated to the alternate format? ArthurPSmith (talk) 13:16, 19 October 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.
It was proposed to use it as a qualifier on DOI (P356) to indicate the name, but if we actually want to store these names there I think we should rather use a generic property for that ("name in registry" or something like that), so that it could be used on other identifiers in the same way.
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 It is different from quantity (P1114). There could be a quantity X of a particular medal that have been produced which corresponds to quantity (P1114), while only a quantity Y has been awarded, which corresponds to P2422 (P2422). Also, P2422 (P2422) is also used for "number of inductees", so if there is a deletion, some would need to be merged to "quantity" as stated above by Pigsonthewing, but the inductees numbers would need to be merged to "membership" property, although it's not as a good as keeping P2422 (P2422). Thanks, Amqui (talk) 16:42, 19 September 2016 (UTC)
Comment the current English label is ambiguous in the first place, and more akin to "quantity awarded", as by its current label it could be interpreted to the number of awards a person has, eg. number of Grammies won. I tend to favour deletion and stop the propagation of "specialist" labels that can suitably covered by something like "quantity". The more specialist labels makes things more difficult for contributors to have to know or guess, and means that when we come to infoboxes people just get it wrong. Our purpose is to help get it right and easier for infoboxes! — billinghurstsDrewth06:53, 5 November 2016 (UTC)
So it means I would put "Quantity: 0" to the Canadian Victoria Cross because it has never been awarded since its inception, but that would mean it doesn't exist with a quantity of 0, but at the same time I can take a picture of it since it does physically exist... How does it make sense? I support renaming it to "quantity awarded" to make it more clear though. Amqui (talk) 15:53, 6 November 2017 (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) 03:38, 19 November 2017 (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.
Keep I agree the property has not been used as much as it could, however I don't think this should be a reason to delete it. I'd suggest we focus on a pilot to meaningfully populate it and showcase its use. I also don't fully understand the second reason: a funder ID is not the same as a DOI, even though a funder can be uniquely referenced via a combination of its ID and a dedicated DOI prefix. Finally, the formatter URL is the one provided by Crossref as part of the funder ID specs, but we could change it to take the same value as the RDF URI scheme (http://data.crossref.org/fundingdata/funder/10.13039/$1).--DarTar (talk) 02:35, 4 November 2017 (UTC)
Keep The values of the property Open Funder Registry funder ID (P3153) can be written as one simple number, e.g. 501100000831, or as a DOI with fixed prefix, e.g. 10.13039/501100000831. This was already discussed in the property creation, but voted aggainst using simply DOI. The Mix'n'Match catalogue #338 does not respect that. I also think that it is better to have different properties for DOI, which are mostly used for publications, and this funder's ID. Thus we should change the Mix'n'Match catalogue and additionally replace all DOIs starting with 10.13039 by the corresponding funder's ID. This will then immediately increase the number of times this properties is used to several thousands. Moreover, change the resolving url as suggested above, or simply the DOI resolver. --Zuphilip (talk) 09:04, 5 November 2017 (UTC)
@DarTar, Pigsonthewing, Zuphilip: Again I am responsible for a good chunk of these DOI uses - simply because I knew that Fundref IDs were part of the DOI system, and I was not aware of this property (as it was unused)… that really stresses the importance of actually using the properties you create within a reasonable amount of time. Once the excitement of the proposal is gone, please do not abandon your brainchildren like this, as they want to rise and shine! Feel free to carry out the replacement that you propose. − Pintoch (talk) 15:42, 6 November 2017 (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.
Delete It seems oddly named and defined in any case. If something cannot legally be photographed I would think a more direct "photography disallowed" property would be better. ArthurPSmith (talk) 19:29, 4 December 2017 (UTC)
Delete Unused. Freedom of panorama is complicated issue with many minor differences in different countries, so it is simply impossible to record it this way.--Jklamo (talk) 20:59, 4 December 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.
If we want to qualify the whole statement (de facto (Q712144)), use <new property>.
If we want to indicate that X, Y or Z is "being" W for some kind of purpose (P794 (P794)Chinese Taipei (Q216923), author pseudonyms), use <new property, item version of object named as (P1932)>. (Is one property enough? Or is it still vague so that we need three properties?)
@Swpb: I'm collecting the current usage of the property. It is much more complex than I have thought. I will post it here once I have done the work.--GZWDer (talk) 18:27, 13 February 2017 (UTC)
For author pseudonyms, WikiProject Books is recommending using subject named as (P1810), which might work for other cases where the value in question is actually a name. On the P1810 talk page I have suggested using P1810 as a qualifier to show the preferred name for something in an external database that we have an ID for -- see for example Jan Vermeer van Haarlem the Elder (Q3159680) for how different databases prefer to name the same artist. Jheald (talk) 17:53, 13 February 2017 (UTC)
@Swpb: I think the latter would be very counter-intuitive for anyone trying to write searches. For a property that's almost always used as an external ID to not be present as an ID, but as a qualifier on something else, would (I suspect) almost always be missed. criterion used (P1013) is an interesting idea, but I think it's value should usually be a question not an answer. As for applies to part (P518) I get a bad feeling every time I see it used for something which is not a physical part, or at least a subdivision (of events in time). Applied to a county I would expect P518 to have the value of a geographical area. Perhaps we need a property "applies to facet", or "applies to aspect". Jheald (talk) 17:56, 13 February 2017 (UTC)
@Jheald: Valid point about the latter. As for criterion used (P1013), I've never seen it as limited to geographic or temporal use, and I don't think it would need to be altered to serve this purpose, but I wouldn't oppose a property like you suggest. --Swpb (talk) 18:08, 13 February 2017 (UTC)
Sorry, I meant to write 518 instead of 1013. (I think you did too). Hope I wasn't too confusing! I've gone back and changed it. Jheald (talk) 18:14, 13 February 2017 (UTC)
@swpb: I think you're right that applies to part (P518) isn't correct in this case. I've been wondering what "applies to part" means - is it part of the subject, part of the object, or part of the relationship? The description says it's part of the subject. In fact when I started going through the use cases of P794, I realised we needed three new properties. Two of them we have already proposed: identity of object and identity of subject. We really need a third one for "applies to aspect", alias "status of statement" - "maximum", "minimum", "interim" etc. It's like applies to part (P518) but it's part of the relationship not part of the item, and like sourcing circumstances (P1480) but qualifies the accuracy of the statement, not the accuracy of the sourcing. I'm quite busy today so won't be writing the proposal yet, but will try to do over this weekend. Deryck Chan (talk) 12:10, 1 December 2017 (UTC)
I don't know, I think that may be slicing use cases too thinly. I've already expanded the description of applies to part (P518) to cover "aspects" and the description of determination method (P459) to cover things like minima and maxima, I think object has role (P3831) works well for statuses like "interim" and "acting", and I think sourcing circumstances (P1480) currently covers the accuracy of the statement as well as the accuracy of the sourcing. Can you give an example of a case where none of those existing properties works? Swpb (talk) 13:51, 1 December 2017 (UTC)
Discussion
I also found many other use of this property, some of them are incorrect:
Many uses of this property with value song (Q7366), film (Q11424), etc should be removed by spliting the item to new items [8]
Minor point, but I am a little confused when you're talking about "W is a subclass of Y", when Y appears to be a property. Jheald (talk) 20:49, 13 February 2017 (UTC)
Here's a query for the most commons classes of X, Z, W, with an example of X : tinyurl.com/zn6rj8z
I haven't gone through the whole list yet, but we should perhaps list all the types of proposed "specifically" replacements, and make sure we're happy with them, eg
There's also quite a lot of potential "has role" replacements, where the role would be quite generic eg "antagonist" etc, for the purpose of the character's appearance in the film. But that may be okay. Jheald (talk) 15:40, 14 February 2017 (UTC)
@GZWDer, Jheald: Thanks for that detailed tableǃ I would like to see how many instances of each usage there are, to illuminate the evaluation of the need for new properties. As for specific rows:
Basically, I think there may be a need for a couple of new properties, but I think their description and scope need more fleshing out, and we need to look first to existing properties that may be able to do the job without overly stretching their scope. --Swpb (talk) 16:44, 14 February 2017 (UTC)
Here is an updated query for the most common joint combinations of Y and (class of W): tinyurl.com/hdx3axc. For each it gives an example X and corresponding example W. (Thanks due to User:MartinPoulter for clueing me into the use of "named subqueries" through his example here).
Also this alternative ordering of the same query, showing all the classes of W for a particular Y together: tinyurl.com/hn8fey9
Splitting "as" and "has role" into "subject has role" and "object has role" could go a long way towards clarifying most of these. It tends to follow fairly closely whether Y is one-to-many or many-to-one. In turn the uses on "subject has role" and "object has role" could then be examined to see if any uses could or should be further cascaded down to more specific properties. Jheald (talk) 09:54, 15 February 2017 (UTC)
If you believe the data that's contained should be moved depending on circumstance to different more specific properties, first move the data and then come back when the property is empty. As long as it isn't Keep. ChristianKl (talk) 07:37, 18 February 2017 (UTC)
Without understanding all of the technicalities above, I thought of using this property to better reflect the parameter "founded" in some infoboxes. "inception (P571):1647" is not much of information actually. Was it then founded as a populated place, a village, a city with certain status or whatever? A single entity can be founded several times in that aspect. A city can be burned and founded again! I agree, that this is very difficult to turn into descent language, but I think it at least makes sense semantically. -- 16:14, 7 August 2017 (UTC)~
Sure thing. I'll add use cases I come across to the table if they don't seem to match anything there already. Swpb (talk) 19:39, 28 November 2017 (UTC)
@swpb: Thanks so much for proposing the "identity of subject" property. I think we have slightly different views on where we should draw the boundary between this new property and subject has role (P2868), though we agree on a large proportion of use cases where it is clear that we need a new qualifier for this purpose. Deryck Chan (talk) 23:40, 29 November 2017 (UTC)
Yes, by all means, adjust the boundaries as needed. You have my approval to edit the proposal itself as you see fit. Swpb (talk) 13:49, 30 November 2017 (UTC)
Delete - too language dependent to be genuinely semantic. Thanks to everybody involved in the migration, that seems to be a lot of work. − Pintoch (talk) 09:35, 2 December 2017 (UTC)
Status update
The properties that use P794 (P794) are shown below, alongside with the number of items (X) that use each combination of property and P794 (P794) and the number of targets (W) of P794 (P794):
P794 qualifier use case statistics as of 25 Nov 2017
Gave it a shot with Google Translate – they were using P794 (P794) for a parameter "function" of a military unit; I changed it to use has use (P366). Swpb (talk)
Keep per Wikidata:Property_proposal/Archive/12#P794 this was as a generic qualifier. From the discussion at Property_talk:P1480#de_facto,_interim,_acting and the subsequent edits, it appears that even for people who regularly edit this group of qualifier, it's not possible to determine the exact qualifier reliably. As the information included as value still needs to be in Wikidata in a structured way, there is still a need for a generic qualifier. Obviously, if/when a better qualifier is identified, values can be moved there. To query both, use "|". --- Jura15:45, 13 December 2017 (UTC)
The "generic qualifier" is problematic precisely because it can mean so many different things, and relies on human intelligence to determine which meaning applies, and I think there's broad agreement that this is a problem. Fortunately, the vast majority of use cases have been migrated to more precise properties with no real disagreement. The fact that the few remaining use cases have caused minor disagreement does not justify giving up on the whole endeavor and leaving this "generic (read vague) qualifier" to re-accrue uses of the types that have already been migrated to better properties. I'm absolutely sure we'll come together on the handling of the few remaining cases, and make sure the descriptions of the various qualifiers don't leave room for ambiguity – if the process that's been working well for nearly a year is allowed a very reasonable amount more time to wrap up. Swpb (talk) 21:22, 13 December 2017 (UTC)
It's really unfortunate how this was handled. This was deleted before a correct replacement was found. Now we have many statements moved to qualifiers people agree that they are wrong: Property_talk:P1480#de_facto,_interim,_acting . The correct approach would be move them back and delete later if possible. --- Jura15:01, 19 December 2017 (UTC)
That's just a complete mischaracterization of a very deliberative process. Replacements were found for all use cases, 99% of the time with no controversy at all. In the tiny subset where there was disagreement, no one said that the qualifiers being used were wrong, only that another qualifier might be better (which can still be addressed), and no one but you expressed the thought that the old, generic qualifier would be better, even temporarily. So no, this property was absolutely not "deleted before a correct replacement was found", and it was deleted after extremely thorough discussion and solid consensus. Swpb (talk) 13:56, 20 December 2017 (UTC)
If you want to query uses of sourcing circumstances (P1480) and make sure they're all to your approval, go ahead. Or talk to @Deryck Chan: directly and tell him how "negligent" you think he is, and then see if he's interested in helping you. Whining and being dishonest about a very decisive closure you don't happen to like is accomplishing nothing but making yourself undesirable to interact with. Swpb (talk) 18:09, 20 December 2017 (UTC)
It appears that many qualifiers have been replaced with in incorrect sourcing circumstances (P1480) and still need to be corrected/reverted. Subsequent discussions for a better solution haven't be productive. --- Jura10:29, 7 January 2018 (UTC)
Oppose If there's clear replacement then use that replacement, no more harrasement, otherwise I just will make a fire request aganist your administrator right. --Liuxinyu970226 (talk) 15:04, 7 January 2018 (UTC)
@ChristianKl: please see above. There is a query for them on the talk page of sourcing circumstances (P1480). The contributor who converted them almost immediately realized his error and, as I saw them doing some correctly, I assumed initially that everything had been fixed. Unfortunately, this hasn't moved since and it would be bad practice if we would let them linger there a further couple of months, until an acceptable alternative was determined. --- Jura16:19, 8 January 2018 (UTC)
Whatever change may be decided in 6 months, we still need to clean up this part. As you did the bulk edits, it's expected that you'd clean it up. If you can't do it or don't have the time to do it, please say so. --- Jura17:25, 11 January 2018 (UTC)
I'm of the opinion that we're better off parking these statements with a sub-optimal qualifier than to return them to P794. I disagree with your description that I "realized his error", but I accept that you and a few other editors disagree with me and some other participants of the discussion above who desired to move those qualifiers to sourcing circumstances (P1480), and offered to move the qualifiers again when a better choice of P than both P794 and P1480 is agreed upon. Deryck Chan (talk) 12:38, 22 January 2018 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Notified participants of WikiProject Roads
Delete obviously a duplicate --Pasleim (talk) 11:59, 12 October 2016 (UTC)
Oppose In many cases the grave is just a simple stone. Does a simple stone warrants an item? — Finn Årup Nielsen (fnielsen) (talk) 16:51, 21 November 2016 (UTC)
Keep I don't think we should make items for individual burial plots in cemeteries and you haven't provided any reason why we should. - Nikki (talk) 10:40, 10 December 2016 (UTC)
and this one should be deleted/redeployed with a domain of iso norms. For example I just put it on ISO/IEC 80000 (Q568496) 
⟩ located in the administrative territorial entity (P131) 
Weak oppose certainly on UK trunk routes "primary destinations" are a specifically defined subset of places served - e.g. M5 motorway (Q1824663) has 12 primary destinations but serves dozens to hundreds of places of various sizes depending how you look at it. I can see value in broadening place served by transport hub (P931) to something like "place served by port, airport or station" but I don't think merging it with a specific property is the best way forward. Thryduulf (talk) 20:53, 15 August 2016 (UTC)
Validate the property isn't being used in other projects (using 
Delete: Obviously an unfit closed Dataset. --Succu (talk) 21:00, 4 October 2016 (UTC)
Weak oppose (changed from "Keep") I would like for us to link to OSM too, not just the other way around, as it makes some queries simpler from Wikidata. But I don't sufficiently grok the different properties needed for that, and I have the feeling that some people in the OSM community seem to be opposed to have datasets uploaded. Before these datasets are lost, I'd like to see them added to Wikidata and preserved. But I have not sufficient background on the relation between Wikidata and OSM, and how OSM is doing things. (The rest is old comment) OSM seems to be reluctant to accept Wikidata IDs and, even if in, rather quick in deleting them again, which leads to a loss of information. Even if the IDs are not 100% stable, we can at least save them here. The important thing is that these IDs are not reused, even when they change, so that we don't accidentally link to the wrong thing. I would suggest to keep this property here and to extend its coverage considerably. --Denny (talk) 22:51, 28 November 2016 (UTC)
Weak support from me. --Glglgl (talk) 16:04, 14 December 2016 (UTC)
Question These IDs are assigned by the WHO or the FDA? Wostr (talk) 17:21, 5 March 2017 (UTC)
Keep: Comments linked with by this property are under CC0. Talk pages are given under CC-BY-SA. CC0 (talk) 19:31, 29 October 2016 (UTC)
Info I started a discussion at Property talk:P2781#Improve definition and invite all interested users to participate. —MisterSynergy (talk) 10:59, 10 February 2017 (UTC)
WikiProject Informatics has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. because this property is about software version type). — Metamorforme42 (talk) 17:40, 2 March 2017 (UTC)
WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. --Succu (talk) 21:56, 15 May 2017 (UTC)
Support to move this property from external-id to string datatype. --Pasleim (talk) 10:59, 26 December 2016 (UTC)
Info The initial discussion started at Wikidata:Bot_requests#NSW Flora IDs.
Merged Matěj Suchánek (talk) 07:39, 24 August 2017 (UTC)
Notified participants of WikiProject Roads
Strong oppose - real problem with https://wikimediafoundation.org/wiki/Privacy_policy --Hsarrazin (talk) 08:07, 25 August 2017 (UTC)
Neutral this property shouldn't have been created until a consensus had been reached on how to use it but now that is has been created, I see no real reason to delete it. PS: I have no illusion, the property is not really the issue here, with or without this property, the exact same data can, were and will be stored (prior to this property creation there was already a hundred of wikimedia user name store in various ways). Cdlt, VIGNERON (talk) 13:44, 25 August 2017 (UTC)
Deleted Matěj Suchánek (talk) 19:40, 4 November 2017 (UTC)
