Open main menu

Wikidata β

Wikidata:Project chat

Wikidata project chat
Place used to discuss any and all aspects of Wikidata: the project itself, policy and proposals, individual data items, technical issues, etc.
Please take a look at the frequently asked questions to see if your question has already been answered.
Please use {{Q}} or {{P}}, the first time you mention an item, or property, respectively.
Requests for deletions can be made here. Merging instructions can be found here.
IRC channel: #wikidata connect
On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2018/04.

Xantus's MurreletEdit

See also User:Pigsonthewing @ Xantus's Murrelet (Q46338167) --Succu (talk) 21:38, 25 February 2018 (UTC)

We seem to be having a problem at Xantus's Murrelet (Q46338167), which User:Succu persists in repeatedly (five times, so far) trying to merge into one or another item about patently different concepts; or from which he removes cited statements. Given previous difficulties I and other editors have experienced when attempting to discuss similar matters with that user, I'm raising it here, and not on the item's talk page which presumably has no other watchers. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:16, 26 December 2017 (UTC)

And a sixth. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:34, 26 December 2017 (UTC)
Mind to count your own reverts too? The item was originally created for the eBird entry xanmur. This is about two species called en:Xantus's murrelet (= Scripps's Murrelet (Q3120531) and Synthliboramphus hypoleucus (Q1276043)). Then Mr. Mabbett added ABA bird ID (P4526) = xanmur, witch is referring only to the common name „Xantus's murrelet“ and a duplication of the value ARKive ID (P2833)=xantuss-murrelet/synthliboramphus-hypoleucus. Finally (after some reverts) he claimed taxon name (P225) = Synthliboramphus hypoleucus (=Synthliboramphus hypoleucus (Q1276043)) about this item. Maybe he could explain here, why and on what base he thinks this is a „patently different concept“. --Succu (talk) 21:00, 26 December 2017 (UTC)
I'm glad that Succu has confirmed that the item in question is about a different concept to the items to which he has variously redirected it (albeit he is confused as to why this is so; and about the edits I have made to the item). Perhaps he will now cease doing so? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:14, 26 December 2017 (UTC)
I'm confirming nothing. I asked for an explaination. --Succu (talk) 21:17, 26 December 2017 (UTC)
"The item ... about two species called en:Xantus's murrelet (= Scripps's Murrelet (Q3120531) and Synthliboramphus hypoleucus (Q1276043))". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:51, 26 December 2017 (UTC)
Hence the first merge. Is this item about two species? Would be nice if you could explain your viewpoint to other readers of this topic. --Succu (talk) 21:59, 26 December 2017 (UTC)
Your first merge was to an instance of Wikimedia disambiguation page (Q4167410). My viewpoint is that Q46338167 represents a different concept to any of those with which you have tried to merge it. I'm also sure "other readers" can read both the item's description, and the sources used. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:24, 26 December 2017 (UTC)
So no explaination at all, why your new item is a „patently different concept“. Different from other species? Repeat: Is this item about two species? Would be nice if you could explain your viewpoint to other readers of this topic. Looks like are unwilling to do so, Mr. Mabbett. --Succu (talk) 22:33, 26 December 2017 (UTC)
To make it easier fr you, is your new item Xantus's Murrelet (Q46338167) about:
  1. the two species Scripps's Murrelet (Q3120531) and Synthliboramphus hypoleucus (Q1276043)) supported by xanmur
  2. the common name „Xantus's murrelet“ supported by ABA bird ID (P4526) = xanmur
  3. the species name Synthliboramphus hypoleucus (Q1276043) supported by ARKive ID (P2833)=xantuss-murrelet/synthliboramphus-hypoleucus
If your answer is "all of them" (=current status) then please explain it to us. Thanks in advance. --Succu (talk) 22:58, 26 December 2017 (UTC)
No Succu, there's explanation aplenty. My reason for raising the matter here is to solicit third-party input. I won't be answering questions such as yours, based on false premises. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:24, 27 December 2017 (UTC)
Then please list my „false premises“ and explain me why they are wrong. But I don't think you have some real arguments. Otherwise it would be easy to you to give them. By the way: Do you think giving only a ISBN like 0198540329 is a sufficient source? --Succu (talk) 21:01, 29 December 2017 (UTC)
OK, I did another merge. --Succu (talk) 22:44, 30 December 2017 (UTC)
Mr. Mabbett? ISBN 0198540329 stands for what book? On which page does this ISBN supports your view? --Succu (talk) 21:14, 23 January 2018 (UTC)
It's a simple question, Mr. Mabbett. Mind to respond? ---Succu (talk) 21:54, 26 January 2018 (UTC)
I don't see a good reason to reply here and generally think it makes more sense to have such a discussion on the talk page by pinging relevant Wikiprojects. ChristianKl❫ 12:59, 27 December 2017 (UTC)
I agree with ChristianKl. I must admit I am completely mystified with what concept Andy Mabbett has in mind. Certainly the item as it now is, seems inconsistent with any way of expressing any concept ever included in Wikidata so far. - Brya (talk) 05:36, 28 December 2017 (UTC)
You're "completely mystified" and - according to your comment on the item's talk page, are "guessing" what it represents; yet you see fit to make changes to the item, which are unsupported by the sources used (and you offer no new sources). That's not a healthy way to proceed. I have again fixed your broken indenting. Wilfully mis-indenting your comments, having been told that doing so is harmful, and having been given advice on how to do so correctly, is disruptive. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:34, 29 December 2017 (UTC)
The problem is that there is very little offered in the way of sources. I see just the ARKive ID link, and given how much junk we already suffered from that source, it is a frail reed to lean anything on.
        And please don't "fix" my comments: you should restrict your religious [?] beliefs to your own comments. - Brya (talk) 11:38, 29 December 2017 (UTC)
There are at least three sources used on the item; none of which are from ARKive. Please stop posting falsehoods. And like I said; disruptive. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:48, 29 December 2017 (UTC)
ARKive ID (P2833)=xantuss-murrelet/synthliboramphus-hypoleucus states this is Synthliboramphus hypoleucus (Q1276043). ---Succu (talk) 21:01, 29 December 2017 (UTC)
BTW, same is true for your weblink to the entry at US ECOS. --Succu (talk) 21:10, 29 December 2017 (UTC)

I've just undone a seventh attempt by Succu to delete this item through a merger to an inappropriate target. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:28, 30 December 2017 (UTC)

Please argue here and do not revert blindly. --Succu (talk) 07:05, 31 December 2017 (UTC)
And an eighth... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:02, 31 December 2017 (UTC)
  Comment Perhaps it's time to find a source that they are actually different... Matěj Suchánek (talk) 21:10, 31 December 2017 (UTC)
You can find one on Xantus's Murrelet (Q46338167). HTH. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:18, 1 January 2018 (UTC)
Then the easiest way to settle the matter is to cite your "reference" here. --Succu (talk) 13:56, 1 January 2018 (UTC)
The American Ornithological Union checklists "are the official source on the taxonomy and nomenclature of birds found in this region, including adjacent islands." see here: http://www.americanornithology.org/content/checklist-north-and-middle-american-birds . Looking at the current checklist here: http://checklist.aou.org/taxa/ we have Synthliboramphus scrippsi (Scripps's Murrelet) and Synthliboramphus hypoleucus (Guadalupe Murrelet). Therefore I believe, officially Xantus's Murrelet has been split, I don't think what other authorities say is relevant. A species with name Synthliboramphus hypoleucus (Xantus's Murrelet) was deleted from the AOU list as per the 53rd supplement in 2012 http://americanornithologypubs.org/doi/pdf/10.1525/auk.2012.129.3.573 I'm not really a wikidata expert, but I would suggest the best course of action is to retain Xantus's Murrelet (Q46338167) but change the instance of (P31) from taxon (Q16521) to something which indicates that this is a formerly recognised taxon, but which has been deleted. I had a quick look but couldn't find an item that would describe that, but this must have happened before. Species are split all the time. I don't really think that Xantus's Murrelet (Q46338167) should be merged into Synthliboramphus hypoleucus (Q1276043) they are different. Just my twopenneth. JerryL2017 (talk) 15:23, 1 January 2018 (UTC)
Wikidata follows a NPoV policy, not a Single Point of View policy; for that try Wikispecies. So, the American Ornithological Union checklists are only one source, not THE source. Of course, it may be possible to start creating items based only on American Ornithological Union concepts, but this would be a fairly big departure from existing practice. - Brya (talk) 05:37, 2 January 2018 (UTC)
We do not model different taxon concepts this way. Thats why I merged the items several and was asking for a good reference to proceed. None was given. --Succu (talk) 16:04, 2 January 2018 (UTC)
Here is the defining reference that concludes Xantus's Murrelet (Q46338167) is 2 species: http://www.bioone.org/doi/full/10.1525/auk.2011.11011 based on that paper the AOU adopted that taxonomy as detailed in the 53rd supplement, http://americanornithologypubs.org/doi/pdf/10.1525/auk.2012.129.3.573 which I had already given above. However, given that not all sources have yet adopted this taxonomy, and based on what others have said here and what is stated in the wikidata taxonomy project guidance it would seem sensible to retain Xantus's Murrelet (Q46338167) for the time being, with the correct links to sources that are still using the former taxonomy. That said, there are issues with Synthliboramphus hypoleucus (Q1276043). This item refers to the "split" Guadaloupe Murrelet but has links to sources that do not recognise the split. It also includes the alternative name of Xantus's Murrelet, which is confusing. JerryL2017 (talk) 17:44, 2 January 2018 (UTC)
Rangewide population genetic structure of Xantus's Murrelet (Synthliboramphus hypoleucus) (Q29541111) is proposing a taxonomic opinion about elevating the two subspecies Synthliboramphus hypoleucus hypoleucus (Q47012916) and Synthliboramphus hypoleucus scrippsi (Q47012925) of Synthliboramphus hypoleucus (Q1276043) to species level. The American Ornithological Society (Q465985) was following the recommendation. I do not see Xantus's Murrelet (Q46338167) is expessing this. --Succu (talk) 18:37, 2 January 2018 (UTC)
Yes, whatever the intent is, execution seems sloppy. - Brya (talk) 04:01, 3 January 2018 (UTC)
Since Mr. Mabbett refuses to argue here I will merge both items once again. --Succu (talk) 19:27, 5 January 2018 (UTC)
And if you do, absent a consensus here, you will be reverted again; for the reasons already given. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:01, 5 January 2018 (UTC)
I expected this. Other people try to argue. Your are not. What a pitty for you. Hopefully you do not miscount your reverts. --Succu (talk) 22:10, 5 January 2018 (UTC)
And this revert of him. --Succu (talk) 07:21, 6 January 2018 (UTC)
And this revert of him. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:35, 6 January 2018 (UTC)
Obviously you are unwilling to give a reasonable answer here. Probably you can't and are defending the item only because you've created it. --Succu (talk) 21:02, 6 January 2018 (UTC)
No progress here from Mr. Mabbetts side. --Succu (talk) 21:01, 8 January 2018 (UTC)
Now at AN. --Succu (talk) 20:59, 9 January 2018 (UTC)
ok from the point of view of a taxonomist. Reading the paper from 2011 linked above by @JerryL2017: the two taxa in question were considered subspecies, however overlap and do not interbreed in sympatry. By the definition of a subspecies this is not possible, hence they should be species and have been recommended as such by the paper also. As such from this viewpoint you have two species and should have two items one for each. Any other refs, unless you find one that refutes this primary ref with data not opinion, are irrelevant. I see no reason for any further argument. The nomenclatural act has been made, follow it. Where the common names go whatever, they are vernacular names and not relevant to the concept of the species. That is my view on this so I would suggest fixing the pages to reflect this and as for the IOC, ummm they are not a primary taxonomic reference so why would you be adamant about it. Cheers Scott Thomson (Faendalimas) talk 21:46, 13 January 2018 (UTC)
All major bird checklist (including IOC) followed this viewpoint. The "official" english common name of Synthliboramphus hypoleucus was changed from „Xantus’s Murrelet“ to „Guadalupe Murrelet“. --Succu (talk) 22:57, 13 January 2018 (UTC)
Xantus's Murrelet (Q46338167) represents a concept, described by the three reliable source used on that item, which we can refer to, for the sake of brevity as "A". You are saying that a different source refers to the concept "B". The Wikidata model, as I understand it, is that to concepts should be represented by different items, (with, if applicable, mutual "said to be the same as" properties). However, If your contention is that "A" and "B" are the same concept, but with different attributes, then the Wikidata model is to include properties with values stating both attributes, cited to their respective sources. What the Wikidata model does not do, is to pretend that the (reliably-cited) concept "A" does not exist. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:17, 13 January 2018 (UTC)
Name it (the concept)! --Succu (talk) 23:23, 13 January 2018 (UTC)
Umm..... I am seriously not getting this. Ok three reliable sources, I looked on the page I did not see anything I would consider as reliable. Please correct me if I am wrong, do you have separate pages for the scientific name and the vernacular names?? I do not understand why you would do that, but no matter. The vernacular name needs to follow the scientific name according to the most recent primary sources. No I do not consider the collective political opinions of eBird or the IOC nd simalar checklists as primary sources. When the species was split I imagine this did require modification of the accepted common names. As such you would use the primary refs that state this coupled with the research paper that did the nomenclatural act to move the common names accordingly. By the way, a taxon is not a concept it is an hypothesis, the concept is the theory of how species are differentiated, ie the grounds for calling something a species. That is for example the Biological Species Concept. However a species is a hypothesis circumscribed under a concept of the primary authors choosing. So please what are we getting t here cause your paragraphh Andy makes no sense. You are reporting science, it needs to reflect science. Cheers Scott Thomson (Faendalimas) talk 23:48, 13 January 2018 (UTC)
OK, I will try and summarise and make some recommendations. Up until about 2012/2013 the ornithological world recognised 5 species in the genus Synthliboramphus (Q287293) . One of these species had the latin name Synthliboramphus hypoleucus, common name Xantus's Murrelet. This is Xantus's Murrelet (Q46338167). In 2012, in the paper cited above, it was proposed that the 2 recognised sub-species of Xantus's Murrelet (Q46338167) (Synthliboramphus hypoleucus scrippsi (Q47012925) and Synthliboramphus hypoleucus hypoleucus (Q47012916) be considered separate species and that Xantus's Murrelet (Q46338167) be deprecated. This hypothesis was accepted by the American Ornithological Union (they have a scientific committee which decides on such matters) and their taxonomy was updated so that the genus Synthliboramphus has 6 recognised species including: Synthliboramphus hypoleucus, common name Guadalupe Murrelet (Synthliboramphus hypoleucus (Q1276043) AND Synthliboramphus scrippsi, common name Scripps's Murrelet (Scripps's Murrelet (Q3120531)). Subsequently a number of other sources have also adopted this new taxonomy (and I make no comment about how reliable these might or might not be) e.g Avibase ID (P2026), IUCN taxon ID (P627), eBird ID (P3444) and others. However a number of others, that are variously cited in wikidata's items have not adopted the new taxonomy. How do I know they have not adopted the new taxonomy? Because when you look at it in detail it does not include Scripps's Murrelet (Q3120531). Examples of these include: NCBI Taxonomy ID (P685)), ITIS TSN (P815) and WoRMS-ID (P850) although there are probably others, I haven't yet reviewed all sources. So, why have these sources not adopted the new taxonomy recommended by experts in the field? I can see 3 reasons: 1) They don't agree with the hypothesis that Xantus's Murrelet is actually 2 separate species - I believe this is unlikely in this case) 2) They haven't updated their taxonomy (highly likely) and over time will probably update their data. 3) They have a scientific requirement to retain Xantus's Murrelet in their taxonomy because of pre-existing data that was linked to Xantus's Murrelet and not either of the sub-species. A good example of this is eBird ID (P3444) where their taxonomy has Guadalupe AND Scripps AND (by their nomenclature) an entity called Scripps/Guadalupe Murrelet (Xantus's Murrelet). So, my conclusion is that wikidata should retain Xantus's Murrelet (Q46338167), some sources are still using the former taxonomy and some bona fide sources WILL ALWAYS have an entity that is best described as Xantus's Murrelet. However, having said that there are some outstanding questions we should resolve 1) For Xantus's Murrelet (Q46338167) what is the best instance of (P31). is it taxon or some other concept that better captures its status. 2) The existing wikidiata items should be updated to ensure each item is linked to sources that best reflect that item i.e. Synthliboramphus hypoleucus (Q1276043) should NOT link to sources that have a taxonomy that does not inlcude Scripp's Murrelet. 3) Other data such as images and synomyms should be updated to make it less confusing. (NOTE: if we have agreement on this I am happy to go and make these changes IF I have assurance that they won't just all be reverted). 4) Consideration should be given within the wikidata taxonomy project for additional avian taxonomy properties (some key sources are not available as properties, which isn't helping here) 5) I've seen various comments on here that some sources are "unreliable" if there is a consensus that they are unreliable then why do we retain them? 6) IF we can resolve this case, consideration should be given as to how this is more widely applied within wikidata - for instance it is very common practise across many data recording schemes to "combine" species into groups when they are difficult to identify. I personally think wikidata should be able to reflect that, we are a broad data resource not a wildlife taxonomy. Thanks, I hope this is useful and moves the discussion on a little. JerryL2017 (talk) 09:58, 14 January 2018 (UTC)
Maybe just a slip of a pen, JerryL2017: „the genus Synthliboramphus has 6 recognised species“ but I count only five... --Succu (talk) 23:16, 14 January 2018 (UTC)
Sorry Succu, you are correct.

────────────────────────────────────────────────────────────────────────────────────────────────────ok what I have been trying to say is the taxonomic view of the situation, then it is for wikidata to determine how best to reflect the science. In answer to your questions from my point of view. This is a wonderful example of why common names are a pain, unprofessional and honestly useless. I agree with you @JerryL2017: that the issues of different nomenclatures between sources is most likely lack of updating.
1. There are three common names available for 2 species the names Xantus's Murrelet and Guadalupe Murrelet both apply to the scientific name Synthliboramphus hypoleucus however the former is now considered depreciated, and Scripp's Murrelet which applies to Synthliboramphus scrippsi. When the species was split the current common name goes with the species that retained the original combination. There is no justification in retaining the common name Xantus's Murrelet for Synthliboramphus scrippsi, or honestly at all. The name Xantus's Murrelet does not technically apply to a taxon anymore, it is considered depreciated, it is at best an outdated name of historic value only.
2. Agreed, removal of sources that are outdated in their nomenclature will avoid confusion, or if they must be stated have it as "stated in and as" so the the page is generally set up with the current nomenclature but make note of any departures from it without supporting them.
3. Agreed, all information possible should be updated, including where necessary file names and metadata for images. I would not revert anything. Cannot speak for others. But I think if we hammer out an agreed position I believe people are professional enough to follow it.
4. Avian taxonomy should honestly be following the ICZN code, which they do not. Further they have made recent efforts to dictate to other fields of taxonomy that their viewpoint should be followed, to a massive backlash. However, this is not our problem, we present the science we do not revise it. If you feel the need for further avian properties please elucidate these.
5. Your guess is as good as mine. I think there is a generalised tendancy in projects like this to grab every online reference possible, unfortunately with little consideration of the quality of what is presented and no fact checking. Basically the equivalent of google says this, it must be true. Again I think this is also unprofessional, I think sources that are questionable should be examined by wikidata taxonomy project for validity and if rejected they are removed.
6. The act of combining species into groups is I think beyond the realm of a database. This is done through analysis of the given issue. Wikidata should be presenting the data, with reliable and good sources. As best as possible the primary taxonomic literature, in the scope of this issue, the thing that can come out of this is a better discussion on what is a good resource, the acceptance that complex cases need to be analyzed using only primary references, and that in taxonomic issues the relevant codes are the primary determinant on availability and validity. That is, if a name is published in accordance with the Code it is to be accepted as valid or refuted, a point the avian taxonomists breach the code on repeatedly.
Cheers Scott Thomson (Faendalimas) talk 15:14, 14 January 2018 (UTC)

Yes, it was established early on that in the real world there are/have been two circumscriptions for Synthliboramphus hypoleucus. That is not a problem. There appear to be several problems:
  • Is this wider/older circumscription notable enough to rate a separate item of its own?
  • Is this wider/older circumscription indeed what Andy Mabbett intends with Q46338167, given that he has already denied this. If not, what does he intend?
  • Is it worthwhile discussing if Wikidata should have items for concepts denoted by a standardised common name set by some bird organization? These clearly exist, but are they notable enough?
  • Given that bird organizations use deviant 'scientific names' with rules of their own, should we have a property for that? Something like "Avian scientific name" or more general "deviant taxon name, used by special interest groups" (to include butterflies)? Clearly, it is not a good idea to put non-Code-compliant names in P225.
Brya (talk) 18:10, 14 January 2018 (UTC)
I agree with your analysis @Brya: specifically:
Is this wider/older circumscription notable enough to rate a separate item of its own? I do not think so.
Is this wider/older circumscription indeed what Andy Mabbett intends with Q46338167, given that he has already denied this. If not, what does he intend? My impression was that this is what is being suggested here, I also acknowledge Andy has denied this, but I have no idea what the purpose of this is in that case.
Is it worthwhile discussing if Wikidata should have items for concepts denoted by a standardised common name set by some bird organization? These clearly exist, but are they notable enough? I do not think they are notable in any great degree, unless they are a highly notable list. I would encourage the avoidance of confusion as a priority.
Given that bird organizations use deviant 'scientific names' with rules of their own, should we have a property for that? Something like "Avian scientific name" or more general "deviant taxon name, used by special interest groups" (to include butterflies)? Clearly, it is not a good idea to put non-Code-compliant names in P225. I prefer something along the lines of your second option, since it can be applied outside Aves (Birds) this can apply to Amphibians also. But I definitely agree anything that is non code compliant should be avoided in almost any circumstance. Cheers Scott Thomson (Faendalimas) talk 20:43, 14 January 2018 (UTC)
All concepts are still in use at Wikimedia projects: de:Lummenalk is about the old concept, en:Guadalupe murrelet is about the new concept. What e.g. is species:Synthliboramphus hypoleucus is about remains unclear to me. So how to deal with #2) Where should we place a) outdated Wikimedia articles, b) outdated external identfiers (in case we can judge they are) And yes, this thread needs some insights by Mr. Mabbett. --Succu (talk) 23:01, 14 January 2018 (UTC)
The Wikispecies account is about the species in question as part of this, we do not worry so much about common names there as its not really what we are about. Vernacular names get added by people occasionally as they see fit, I ignore them as best as I can. If someone wants to add the english common name they can. Cheers Scott Thomson (Faendalimas) talk 00:54, 15 January 2018 (UTC)
I do not care much about common names, but I care about references. The Wikispecies article has only a reference to the origninal combination Brachyramphus hypoleucus (not mentioning it at all). So it's hard to know about which taxon concept this entry is. :( --Succu (talk) 19:30, 16 January 2018 (UTC)
Fair enough, sorry I do not do the birds. I would not know the relevant refs. When I do turtles I already have pretty much all the literature, so is easier for me. However, since species:Synthliboramphus scrippsi also exists, then the other species can only be considering the new combination. Cheers Scott Thomson (Faendalimas) talk 00:17, 17 January 2018 (UTC)
But this only a guess. Even the genus species:Synthliboramphus has no reference to a current taxonomic treatment... --Succu (talk) 20:38, 19 January 2018 (UTC)

Any suggestions how to resove this „probem“? Mr. Mabbett is not responding. --Succu (talk) 22:04, 30 January 2018 (UTC)

I will update wikispecies with the appropriate refs to show the two currently accepted species, and with a common name for each, with the relevant references (if anyone has them please send them to me) I need the original descriptions of both species and the treatment that recognises them as currently valid species. If you wish then you can use this to model your database entries on this. That is up to you. My suggestion is to follow what has largely been discussed here, in the absence of any other explanation. So I suggest you have data entries for each of the two species with the currently accepted common names for each taxa, with the original refs. I further suggest that you could delete the entry for the now depreciated common name and list it only as an alternative, older, no longer used name for the species Synthliboramphus hypoleucus in older treatments. Cite the paper that split them as species for justifying this. I would suggest calling the two data entries by the scientific name with the common names as description. This way the taxa are clearly defined and it can be noted the common names are less clear. Just my suggestions, your call. Cheers Scott Thomson (Faendalimas) talk 22:17, 30 January 2018 (UTC)
Please refer to my reply to you (so much for not responding!), above, time-stamped "23:17, 13 January 2018 (UTC)". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:13, 30 January 2018 (UTC)
Your usual gibberish, Mr. Mabbett. You didn't responded to some question directed to you (what concept, give a page). --Succu (talk) 22:57, 31 January 2018 (UTC)
OK, I will merge both items again. --Succu (talk) 19:07, 5 February 2018 (UTC)
If you do, I will revert you, because nothing here refutes my reason for doing so previously. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:16, 5 February 2018 (UTC)
Why would you revert? I thought consensus was what was followed here. Cheers Scott Thomson (Faendalimas) talk 12:56, 6 February 2018 (UTC)
So, why would you revert, Mr. Mabbett? Is nothing here refutes my reason for doing so previously an argument? --Succu (talk) 22:51, 7 February 2018 (UTC)
As you can see, my arguments are laid out above. As a courtesy to our fellow editors, I see no need to repeat them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:16, 7 February 2018 (UTC)
As a courtesy to our fellow editors [...], Mr. Mabbett? An „interesting argument“. I'm one of your fellow editors. I don't think you have an answer to my questions, because you are avoiding to give a unequivocally answer for weeks now. --Succu (talk) 22:10, 8 February 2018 (UTC)
Done. --Succu (talk) 22:55, 8 February 2018 (UTC)
This was again reverted by Mr. Mabbett with the comment „per project chat“. --Succu (talk) 20:21, 14 February 2018 (UTC)
Looks like we have to wait till eternity, to get an explaination by Mr. Mabbett. --Succu (talk) 18:40, 20 February 2018 (UTC)

Despite the above, Succu's latest reason for reverting me was "no argument given". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:10, 24 February 2018 (UTC)

Where above? So what's this item about? You didn't tell us. --Succu (talk) 13:32, 24 February 2018 (UTC)
Still no explaination, by Mr. Mabbett. --Succu (talk) 21:53, 24 February 2018 (UTC)
Still no clarification by Mr. Mabbett. --Succu (talk) 06:11, 2 March 2018 (UTC)

I moved the value of ARKive ID (P2833). Could you please explain your revert, Mr. Mabbett? --Succu (talk) 19:14, 6 March 2018 (UTC)

Too busy to answer, Mr. Mabbett? --Succu (talk) 16:13, 13 March 2018 (UTC)
ARKive ID (P2833)=xantuss-murrelet/synthliboramphus-hypoleucus states „Two subspecies of Xantus’s murrelet are recognised“ And this is Synthliboramphus hypoleucus (Q1276043). So please undo your revert or give a reasonable explaination, Mr. Mabbett. --Succu (talk) 15:21, 20 March 2018 (UTC)
OK, then I will do it for you. --Succu (talk) 14:47, 27 March 2018 (UTC)
"Mr. As before" reverted this again. No reason was given. When do you start to argue, Mr. Mabbett? --Succu (talk) 21:36, 30 March 2018 (UTC)
As before: no answer was given by Mr. Mabbett! --Succu (talk) 17:30, 5 April 2018 (UTC)

I stumbled into this one (page-searching for a certain word). I am astonished to see that Wikidata has not been able to solve this December 25 thread? Does not look inviting. 19:49, 5 April 2018 (UTC) -  – The preceding unsigned comment was added by DePiep (talk • contribs) at 19:49, 5 April 2018‎ (UTC).

He likes housekeeping (=unsigned). The answer is easy if Mr. Mabbett would cooperate. --Succu (talk) 20:20, 6 April 2018 (UTC)

Nine days ago I asked User:Rschen7754 how to proceed in cases like this. No help at all. --Succu (talk) 14:31, 13 April 2018 (UTC)

Another week: no progress. --Succu (talk) 13:27, 20 April 2018 (UTC)

Title title (P1476)Edit

Hello. Why title (P1476) should only contain a single value? Some papers and files have two languages on them. For example English and Greek. No one of the language can be called as the original and the other as the translated language. Both are the original languages. Xaris333 (talk) 19:02, 4 April 2018 (UTC)

You can enter both titles, and then edit title (P1476) to have a new "exception to constraint" for this particular item that has two titles. - PKM (talk) 20:39, 4 April 2018 (UTC)
But there are many items. Xaris333 (talk) 22:17, 4 April 2018 (UTC)
@Xaris333: Can you give an example or two, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:51, 5 April 2018 (UTC)
@Pigsonthewing: See Amiantos (Q6377735) --> population (P1082) --> 262. See the source. Xaris333 (talk) 13:33, 5 April 2018 (UTC)
Thank you. I was looking for examples of Wikidata items about such works. Incidentally, you can link to a specific property on an item, like this: Q6377735#P1082. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:06, 5 April 2018 (UTC)
there are also all multilingual editions of books or texts in wikisource, with a link on both ws projects, like no label (Q25991162), which is a whole book, or no label (Q25991163), which is a poem. As all poems and individual works in those multilingual texts are to be referenced, there will be a LOT of them, just for latin authors :)
aaannd cases of poems that are known and published under various titles (in the same edition), like medieval Rutebeuf's see here no label (Q19181898), where 3 different titles are mentioned on the very same page of the same edition :/ --Hsarrazin (talk) 15:21, 5 April 2018 (UTC)

Should we remove the constraint? Xaris333 (talk) 01:20, 6 April 2018 (UTC)

  •   Support removing the single-value constraint on "title". - PKM (talk) 19:42, 9 April 2018 (UTC)
  •   Oppose The overwhelming majority of the cases will still have only a single value, and all too often extra values are added that shouldn't be there. It's not a mandatory constraint, but the constraint is useful for tracking these cases. – Máté (talk) 06:19, 11 April 2018 (UTC)
  • subject >  Wikidata property  object or value >
    as long as it is NOT mandatory, there is no problem for me :) --Hsarrazin (talk) 08:33, 16 April 2018 (UTC)

New constraint to enforce that two properties have the same value on a given itemEdit

There is an ongoing discussion at Wikidata:Property proposal/Directory of Open Access Journals ID and Wikidata:Property proposal/Plants of the World online (among others) about how to link to two different databases which use the same identifier. The simplest solution seems to consist in creating two distinct properties which would generally have the same value when they are present on the same item (but different URLs generated by the formatters). It can be a burden to deal with this redundancy so some editors wonder if a new type of constraint could be created to alleviate that. Would that be an appropriate solution? @Lucas Werkmeister (WMDE): would it be technically feasible? − Pintoch (talk) 08:51, 8 April 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── As I've noted elsewhere, "distinct properties which would generally have the same value" is far from simple, and is in fact a harmful way to proceed. Consider:

for which we currently have Flora of North America taxon ID (P1727) and Flora of China ID (P1747); with a further eighteen potential properties to follow. Sadly, only four people responded when I raised this here and at Wikidata:Requests for deletions/Archive/2018/Properties/1#eFlora properties. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:52, 8 April 2018 (UTC)

This seems to be a slightly different issue as all these URLs come from the same database. I understand that you vocally oppose the creation of these properties but I still don't understand what you are proposing to do instead (specifically for the two proposals linked above)? Third-party formatter URLs are not a solution for this particular problem. − Pintoch (talk) 12:14, 8 April 2018 (UTC)
"Third-party formatter URLs are not a solution for this particular problem" Yes, they are; and that is the solution I have - quite clearly - proposed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:34, 8 April 2018 (UTC)
@Pintoch: I tend to agree with Andy here: we should be using a third-party formatter URL in these cases. Unless there is at least one instance where the identifier differs between, say, P1727 and P1747 for the same item (which judging from Andy's links is in the same database), the two properties should be unified. What should be worked on is a way to control which formatter URL appears on a given item—in this case, based on some sort of geographical information on the item itself. Mahir256 (talk) 18:46, 8 April 2018 (UTC)
@Pigsonthewing, Mahir256: Sorry if it is obvious but I still do not see how you would use a third-party formatter URL to indicate that a given identifier is available in database X but not in database Y? For instance, not all ISSNs can be found in DOAJ. Also I don't see in which context the third-party formatter URL is actually used to generate a link for the identifier in the Wikibase UI? It would be great if you could give a very concrete example of this, because I think that I am not the only one who does not get it. − Pintoch (talk) 19:13, 8 April 2018 (UTC)
Couldn't we create a property for journals like IndexedIn:DOAJ ? --Gerwoman (talk) 19:17, 8 April 2018 (UTC)
To piggyback off Gerwoman's suggestion, why not have the formatter URL change based on a reference "stated in (P248) Flora of China (Q5460442)" or "stated in (P248) Directory of Open Access Journals (Q1227538)" as appropriate? Mahir256 (talk) 19:22, 8 April 2018 (UTC)
That's intuitively harder to implement, but why not. As far as I understand Andy claims that somehow no change is needed and third party formatters already provide a solution. − Pintoch (talk) 21:36, 8 April 2018 (UTC)
While it is not necessary to "indicate that a given identifier is available in database X but not in database Y" (that's what the 404 response code is for), it is possible to do so, using referencing, as I have demonstrated previously. You were apparently aware of the example I gave then. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:36, 9 April 2018 (UTC)
As I understand it, people just want to have a hypertext link to the said databases. Manually constructing the link from a third-party formatter URL and checking if it resolves correctly might be an option for bots, but not for people. So even if I like the idea, I don't really see how this method is a solution: that involves statically instantiating the third-party formatter URL for the given ID (which makes it hard to update the URLs if the format of the website changes). And I guess it is not very convenient for users either, as they have to expand references to check if there is a link there. I am not really speaking for myself here: I just notice that there are quite a lot of support votes for these properties, and I am worried that by refusing their creation we are going to make their life harder. − Pintoch (talk) 14:22, 9 April 2018 (UTC)
Hello all,
Feel free to create a ticket on Phabricator, with the tags Wikidata and Wikibase-Quality-Constraints. Don't forget to provide examples of what you need. Is this related to this specific property, or would you need it for others as well? We'll have a look as soon as possible.
Cheers, Lea Lacroix (WMDE) (talk) 15:20, 9 April 2018 (UTC)
Thanks! I have created a task here: https://phabricator.wikimedia.org/T191963Pintoch (talk) 09:49, 11 April 2018 (UTC)
"people just want to have a hypertext link to the said databases" Perhaps. But given Wikidata's purpose, is that the right thing for us to do? "I want" is not a very compelling use-case. "that involves statically instantiating the third-party formatter URL for the given ID ". No, it involves giving a valid citation for the data; and happily also meets your requirement to "indicate that a given identifier is available in database X but not in database Y". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:43, 9 April 2018 (UTC)
The ID overlap between FNA and FOC is around 2,500. This will produce more than 40,000 404 errors. --Succu (talk) 19:33, 13 April 2018 (UTC)

Despite this ongoing discussion, and despite the lack of examples of the type requested in its property proposal, Plants of the World online ID (P5037) has just ben created. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:34, 11 April 2018 (UTC)

One example: Byttneriaceae (Q2548700) in POWO has no entry in IPNI. --Succu (talk) 18:08, 13 April 2018 (UTC)
  • This thing happened here too. The proposal passed. strakhov (talk) 20:27, 16 April 2018 (UTC)

Ancient and modern citiesEdit

Should the relationship between Londinium (Q927198) and London (Q84) be <followed by/follows> or <replaced by/replaces>? - PKM (talk) 23:38, 8 April 2018 (UTC)

<followed by/follows>, if I read the follows (P155) description right: "Use P1365 (replaces) if the preceding item was replaced, e.g. political offices, states and there is no identity between precedent and following geographic unit". There is an identity in the continuum of London. --Tagishsimon (talk) 23:43, 8 April 2018 (UTC)
Great, thank you. - PKM (talk) 23:46, 8 April 2018 (UTC)
@PKM, Tagishsimon: follows (P155) is supposed to only be used as a qualifier, according to the constraints. --Yair rand (talk) 06:29, 10 April 2018 (UTC)
Yes; sigh. The constraint forces us to define the domain of the observed sequence.
Perhaps
or more colloquially  ? --Tagishsimon (talk) 06:52, 10 April 2018 (UTC)
Or kill the constraint. I suspect it's used "incorrectly" (i.e. not as a qualifier) at leastr as often as it used "correctly" according to the constraint. - PKM (talk) 20:14, 12 April 2018 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── From the SQUID poperty browser:

  • followed by (P156) used as Statement: 381,522 Qualifier: 77,925
  • follows (P155) used as Statement: 391,115 Qualifier: 78,487

This constraint is a lost cause. - PKM (talk) 21:36, 13 April 2018 (UTC)

  • Sigh. But this constraint is not accidental - using these properties as main properties makes semantics more ambiguous: one cannot tell in which sequence they are "next/previous". The other solution was always to mark sequence as a qualifier with P361 or better series (P179). But this approach seems to be even more rare. --Infovarius (talk) 09:29, 15 April 2018 (UTC)
So how could we fix these ~300k "errors"? It seems we'd need to convene a task force or some such, to make or find a sequence/series that is appropriate and then edit them all. - PKM (talk) 19:35, 15 April 2018 (UTC)

More than 50% of my edits get reverted. And "Days of The Week" are separated into 2 items; undiscussed.Edit

  1. Everything starts with one day I find that the Chinese, English, Deutsch version of the "Days of the Week" are not connected. 42 languages are in one group and 11 languages are in the other group, and I found no discussion about the split in Wikidata or the English Wiki, so I merged them. And then I got reverted by User:Andreasmperu. So I merged them with a message "No one single language separates this exact same topic. No separation discussion found in wikidata or english wiki of the topic 'Days of the week'", and leave a comment on the Talk:Q41825 "Separation will create unnecessary difficulties to compare difficult languages of the 'Days in the Week'.". And then I got reverted by the same admin again with just two words "wrong item" with no reply on the discussion page. [1] [2]
  2. As a result, more than 50% of my edits in Wikidata get reverted without a reason. If you do Google translate, you will know these two are the same topic "a ship destroyed and sank".
  3. G translate will tell you that these two(w:en:Chuanyue) are about the same topic of "Time Travel Fiction".
  4. Click in to look at the map and coordination and you know one is about the same town, and the other is not a town.
  5. You don't even need Google translate to know these two are the exact same group of Baptist Universities. Just spend 5 seconds to click in.

What an irony that an IP user is more willing to explain and communicate than an administrator. 118.143.147.130 22:01, 9 April 2018 (UTC)

In the first case, you seem to have conflated "Names of the days of the week" with "Day of the week". That's an error, since those are different concepts, and was rightly reverted. Similarly, not all time travel in fiction is a time travel novel. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:24, 9 April 2018 (UTC)
Per Andy, you in fact get 5/5 wrong.
  1. Two different concepts, names of days of the week versus day of the week.
  2. Disambiguation page versus article
  3. As noted, not all time travel in fiction is a time travel novel; different concepts.
  4. zh.wiki has articles attached to both items. You'd need to sort that out before they could be merged.
  5. Disambiguation page versus list article. You can argue that zh.wiki should change their article to a list, but until they do, it's a dab, and we need to reflect that.
So. Sorry about that. --Tagishsimon (talk) 22:54, 9 April 2018 (UTC)
  1. The English Wiki "Names of the days of the week" is actually the same article moved from "Days of the week". What topic of contents is different before the en-wiki article moved from "Days of the Week" and after moved to the current "w:Names of the days of the week"? They are still all about the exact same topic: how to count the seven days, their astronomy origins and their names in different languages. "No one single language Wiki separates this exact same topic into two articles" is the strongest evidence that none of the 53 languages thinks that they are about different topics.
  2. I don't think good idea to separate the exact same topic of different languages simply because one has less content. This will break the cross-reference and cross-improvement connections among different languages.
  3. Of course, fiction includes novels and films. It is wrong to say that "小說" in Chinese only includes written books. 小說 does include films and other forms of art, so 穿越小說 is same as "Time travel in fiction" and both of them include "Time travel novel". Google translate tells you the same 小說=Fiction Fiction=小說.
  4. I wonder whether you guys did click in for 5 seconds. w:zh:金字牌鎮 and w:sv:Jinzipai (köpinghuvudort i Kina, Anhui Sheng, lat 29,85, long 117,81) are the same location at (29.85 N, 117.81 E). w:zh:金字牌 is a "message certificate of royal orders", which is definitely not a location.
  5. Bad idea to separate the exact same topic of different languages; not to mention even their content are the same. So if I change the w:Baptist University to disambiguation, this one is done? 118.143.147.130 12:24, 10 April 2018 (UTC)
  1. (All IMO...) This one is something of a clusterfuck. The two wikidata items are distinct and for that reason should not be merged. However I concede that there are claims and wikilinks on day of the week (Q41825) that belong instead on names of the days of the week (Q42962347) or on another item (e.g. the GND ID seems to point to a concept of 'Working Days'). I concede, too, that not much may be left on day of the week (Q41825) by the time we finish.
  2. These remain two distinct items, one pointing to articles on concept of shipwreck/ing, the other a zh disambiguation page. zh's article on shipwrecks was pointed at the wikidata item maritime disaster (Q2620513) ... I've moved it to shipwrecking (Q906512). I think that's now sorted?
  3. So for this one ... time travel novel (Q10453828) is a distinct subclass of time travel in fiction (Q253732) and the two should not be merged. The zh. wikilink from time travel novel (Q10453828) looks appropriate; is about tt novels. The en. wikilink was to an article on Chuanyue which is a distinct subclass of time travel novel (Q10453828) ... I've created a new item, Chuanyue (Q51733250) and moved the en. wikilink to it. I'm hoping we're good on this now.
  4. This one should be sorted now.
  5. Yes; I've done that. With luck, also sorted.
More generally, you'll not get much dispute that there is a lot wrong or that can be improved in many wikidata items. Exactly how to effect improvement can be a more thorny issue. --Tagishsimon (talk) 00:47, 11 April 2018 (UTC)
@Tagishsimon: I'm afraid that I have to bump WD:RFP/R#Andreasmperu again here. --Liuxinyu970226 (talk) 10:11, 11 April 2018 (UTC)

IAFD person Ambiguity propertiesEdit

There is an ambiguity with the IAFD person properties on Wikidata, IAFD male performer ID (P4505) and IAFD female performer ID (P3869), the correct one would be to only exist an "IAFD person ID" as like Adult Film Database person ID (P3351) . I believe that this ambiguity occurred because of the second parameter gender. It was mistaken for a secondary ID, in fact it is just a layout parameter for the IAFD site.

All links below point to the same element on the IAFD site.

http://www.iafd.com/person.rme/perfid=glynn
http://www.iafd.com/person.rme/perfid=glynn/gender=f/ginger-lynn.htm
http://www.iafd.com/person.rme/perfid=glynn/gender=m/ginger-lynn.htm
http://www.iafd.com/person.rme/perfid=glynn/gender=d/ginger-lynn.htm

This ambiguity makes it difficult to integrate with templates on Wikipedia.

Guilherme Burn (talk) 13:34, 10 April 2018 (UTC)

Note: IAFD is an "adult film" database and the above links may be considered "not safe for work". Having learned that the, er, difficult, way: your first two links return different data. For example, the first link has no picture, while the second does; and the former only lists two films; the latter has 342. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:12, 10 April 2018 (UTC)
Yes @Pigsonthewing:. But that does not justify treating people of masculine, feminine, and "director" genres as different elements. If you repair the first link, without this parameter already have the correct information.Guilherme Burn (talk) 15:32, 10 April 2018 (UTC)

Is it possible to rename a property? If yes, it would be enough to exclude the less used one and renomer another. Of course, if there is consensus.Guilherme Burn (talk) 19:33, 16 April 2018 (UTC)

ICTV taxonomy latest version (Q45362532)Edit

Hi all,

I'm using the virus ICTV taxonomy of viruses to reference viruses on a website I'm working on and I was looking for a linked data format that would help me in keeping these taxonomic references up to date. I was first glad to find on Wikidata a contribution about the ICTV taxonomy (List of ICTV master species list on wikidata) since till now the ICTV website only provides an annual official release of the virus taxonomy in an Excel sheet format with about 1 thousand updates each year over the last releases (https://talk.ictvonline.org/files/master-species-lists/m/msl).

However, I'm interested in having fixed URIs that would have updated content when the taxonomy of these viral taxons are updated by the ICTV (basically updated labels and parent taxons, the previous label could be put in the "Also known as" section or in a more adapted statement ), but on Wikidata it seems that each release of the ICTV taxonomy exists with a kind of independance which is a kind of duplication of the information (cf: List of ICTV master species list on Wikidata): Even if common terms in the different version of this taxonomy are well linked to the corresponding ICTV versions there is an incoherence when the terms are updated since a new URI with the new term is created. For example according to the ICTV history tracking system on taxonomy we can find that the current taxon officialy named Avian avulavirus 7 was previously named Avian paramyxovirus 7 but there is 2 distinct URIs for these terms on Wikidata (Q29004365 and Q18907779). https://talk.ictvonline.org/taxonomy/p/taxonomy-history?taxnode_id=20161025


To me, and probably to most of the virologists, it is crutial to know what is the current ICTV taxonomy (ie:latest version) and keep track of the changes made so that we can know what is the current official name for a taxon (even if updated) and what is its current lineage (even if modified)... At the moment Wikidata is somehow providing a biased exhaustive view of all the existing releases of this ICTV taxonomy.

I'm new to Wikidata and I'm new to Linked data too... so I was wondering if we could ask for a kind of merging contribution named "Latest version of the ICTV taxonomy" that would have fixed URIs for each taxon including the next updates of the ICTV taxonomy without changing the URIs? ... a new URI would only be created for new taxons (not for updates in the taxon names or lineage) and removed taxon in the taxonomy would consequently be marqued as moved to their parent taxon.

@succu: ... Avian avulavirus 7 (Q29004365) and Avian paramyxovirus 7 (Q18907779) both your creations. --Tagishsimon (talk) 01:23, 11 April 2018 (UTC)
Paging @succu: ... would you mind explaining your creation of duplicates, please. --Tagishsimon (talk) 15:12, 13 April 2018 (UTC)
Virus nomenclature is different from that for plants or animals, virus names can be deleted or renamed. The ICTV Master Species List (Q45362532) (the latest is ICTV Master Species List 2017 v1.0 (Q51526638), not complete here) did not contain the former name. You have to connenct the former name manually via replaced synonym (for nom. nov.) (P694), but this connection is not very complete. --Succu (talk) 15:50, 13 April 2018 (UTC)
Thanks Succu. @D3fk dev: I think we aspire to the arrangement you suggest - a single stable item for each virus. Right now the way in which ICTV release information is not conducive to us being able to achieve that. Although the website will provide a change history for each virus, the spreadsheets do not provide specific information on the nature of a change made to virus attributes from year to year. Even the URL for the change history of a virus will change from year to year. ICTV seem to lack, or seem not to promulgate, a primary key value for each taxon; and reserve the right to change all attributes of the virus, including its name. Together, that's a data nightmare. It would take some masterful web-scraping to glean the information we need from the ICTV website, which is a shame, because ICTV clearly have the data that we (and others - you - require). I think someone needs to make enquiries with info@ictvonline.org to see if we can get a release of data that ties together the names of viruses in each of the yearly releases, so that we can start to merge items and provide, as properties and qualifiers, their attributes as they vary over time. --Tagishsimon (talk) 01:29, 14 April 2018 (UTC)
Thanks Succu and Thanks Tagishsimon @succu: @Tagishsimon: Happy to see that you aspire to fix this problem that way. I've been in contact recently with ICTV poeple through the info@ictvonline.org contact point about having access to possible other formats of the ICTV database (ideally Linked Data)... They are really open to create specific releases of their species spreadsheets (actually they are already providing their data in the form of a slightly modified spreadsheet to a number of taxonomic databases including Species 2000 "Catalogue of Life" and the World Registry of Marine Species). They've said that they were planning to find an alternate way to provide their data to the scientific community and the public... I've already suggested Wikidata as the best solution for this and they said they find number of advantages in using Wikidata (I didn't know at that time that there was already a contribution for the ICTV species list on Wikidata). Could you contact them about the ideal format (e.g.: including an ID for each taxon and the previous known names and parent taxon in case of update) for the succubot so that this consistency problem on Wikidata could be fixed in short terms? -- D3fk dev (talk) 9:51, 16 April 2018 (UTC)
@succu: @D3fk dev: I pinged info@ and Prof. Elliot J. Lefkowitz was kind enough to respond ... in short, providing alternate means of access to taxa history data is in their to-do list, but the list is long and the work is done in their free-time. (And they have data gaps in places - e.g. no info in the database as to which of the 1979 taxa were merged, in 1999, into either Human enterovirus C or Poliovirus, in https://talk.ictvonline.org/taxonomy/p/taxonomy-history?taxnode_id=20171985 ) I have not, at this time, asked them to do anything to alleviate our issue; I think we would need to have someone, or a team, ready to work with them before asking them to consider the effort required to provide a special cut of data for us. I'm now thinking that we might be able to make progress with a modicum of web scraping, but need some time to ponder on that. --Tagishsimon (talk) 20:51, 16 April 2018 (UTC)
@succu: @Tagishsimon: good news! However, don't you think that simply having access to a slightly modified version of their ICTV spreadsheet including 1 row per taxon and an additional column for the unique ICTV taxon ID + an additional column for the previous taxon name known + a latest column for the previous parent taxon known... should be sufficient for the succubot to make links within existing data on Wikidata and solve this issue? -- D3fk dev (talk) 7:43, 17 April 2018 (UTC)
There is certainly a tabular data representation to be had which conveys the information we need. Lefkowitz made the point that they had in the past sought to do exactly that, but ended up with a complex hard to understand spreadsheet which was difficult to maintain. I don't think your 2 -line spec covers all of the complexities of merge, split, rename, reparent; and it is because I don't have the headspace right now to think through the issues (because, IRL) that I chose not to persue a suggestion that the volunteers at ICTV redirect their effort to satisfy our needs. Equally, slow time, I'm still looking at their website with a view to scraping. But right now I have a sash-window to dismantle. Very exciting. --Tagishsimon (talk) 11:56, 17 April 2018 (UTC)
@Tagishsimon: Actually ICTV updates complexity could be resumed by :
  • New taxon(= a new ICTV unique ID in the spreadsheet = a new URI to create: solved by the ICTV unique ID column)
  • Renamed taxon (= same ICTV unique ID = same URI on wikidata with changed label and the previous label moved in a "previous/former name" property of the taxon type or in the "also known as": situation solved by the previous taxon name column, the current taxon name and the ICTV unique ID)
  • Moved taxon= reparent (= Same ICTV unique ID, same taxon name but different previous parent taxon name from the current parent taxon name = same URI but changed parent taxon property of the property of the taxon type statement)
  • Moved and renamed taxon (=Same ICTV unique ID, different taxon name from the previous taxon name and different parent taxon name from the current parent taxon name)
  • Deleted taxon (ICTV unique ID not anymore in the taxons list = URI unlinked from ICTV source and marked as deprecated)
"Spliting" might be resumed by the creation of new taxon or a new taxon+ a renamed taxon
"Merging" seems equivalent to a deletion or a deletion + a renamed/moved taxon
I agree that keeping all historical data in a single file would be a mess but if they continue to work with yearly distinct ICTV release files it should be ok.
The main interest of having a dedicated spreadsheets release for Wikidata would be the stability of the data format and the direct implication of ICTV in delivering their data to the scientific comunity and to the public through Wikidata; versus a web scraping only initiated by wikidata that could miss data if ICTV decides to change their web interface. That being said, I hope your sash-window was dismantled and fixed without problem -- D3fk dev (talk) 13:22, 17 April 2018 (UTC)
There is another difference: We accept different taxonomic viewpoints for plants, animals etc. and model them around taxon name (P225). But for virus taxonomy there is only one taxonomic viewpoint, that of ICTV. So your proposal change labels etc. is not working in the general context how WD handles taxonomic issues. But WD should be able to keep track that the species Bovine papilloma virus from the ICTV 1st Report (MSL #01) in 1971 evolved into Deltapapillomavirus 4 (Q18972422), Epsilonpapillomavirus 1 (Q18972592) and Xipapillomavirus 1 (Q18972997) today. A additional column for renamed taxa would help ofcourse. --Succu (talk) 15:34, 17 April 2018 (UTC)
@succu: Yes, you're right ICTV represents on the web only 'one' taxonomic viewpoint on the virus taxonomy information available through the web and ICTV with their yearly update system probably works somehow differently than others in the world of taxonomy ... but this ICTV point of view on virus taxonomy is recognized within the complete virologist community as the single Official taxonomic viewpoint on "virus taxonomy" and all the other taxonomic viewpoints existing on the web at the moment that are different from the ICTV point of view on the virus taxonomy are just late to catch up on the ICTV taxonomy(eg: Species 2000 "Catalogue of Life", the World Registry of Marine Species, or even the NCBI taxonomy that mentions "The NCBI taxonomy database is not an authoritative source for nomenclature or classification - please consult the relevant scientific literature for the most reliable information.").
So trying to retranscribe in Wikidata all existing virus taxonomies through the web at a moment is really confusing since it participates to maintain deprecated nomenclatures in the world of viruses nomenclature. It would be wonderfull if Linked data could make more sense in the world of taxonomy and not simply tending to be exhaustive.
Moreover, if URIs of the ICTV virus taxonomy could be fixed with updated labels on taxon updates by ICTV (as well as updated statements on parent branching and naming history), Wikidata could became a wonderfull tool for spreading an up to date virus taxonomy to the world.... Simply imagine how wonderful it would be to simply have to reference a WD taxon URI once and to get the latest known name and lineage for this taxon at each request! Wikidata would become for sure the main data provider for most of users of the virus taxonomy. To reach that goal the Wikidata bot used for virus taxonomy could be adapted to handle the virus taxonomy slightly differently from other kingdoms taxonomies... simply in order to make more sense within the data. You're right that WD should also be able to keep track of the evolution of the species/taxon names (history allows to catch up on the current taxonomy), but it could be done by recreating a new URI for the former species/taxon names at each ICTV taxon update. A subclass of taxon (Q16521) like "Former taxon" or "Historical taxon" could be imagined or even a subclass of taxon name (P225) like "Former taxon name" could be useful. At the moment on WD we can find several instances of a taxon for a current taxon and all the historical versions of this taxon but in reality it is question of the same taxon that was renamed but WD doesn't link this information for now -- D3fk dev (talk) 8:22, 19 April 2018 (UTC)
This will not work. E.g. what should we do with abolished (deleted) names. Delete them here too? Different taxonomic viewpoints are represented here by references (at least we try). A SPARQL query like this should give you all the accepted names according to ICTV Master Species List 2017 v1.0 (Q51526638) (no guarantee it does indeed). There is another problem: There are a lot of older Wikipedia articles never got updated to the newest "offical viewpoint". Even Wikispecies host track. --Succu (talk) 19:34, 20 April 2018 (UTC)

Change a birth date on a protected pageEdit

I am not autoconfirmed since I don't edit wikidata. The issue is with María Félix (Q465189). She was born 4 May not 8 April (that's her death date). Google recently made a doodle of the actress mistakenly giving that date as her birthday. Here is a source for her actual birth from the New York Times obituary: "Ms. Félix was born María de los Ángeles Félix Guereña, on May 4, 1914, in Álamos, Sonora, according to the birth certificate discovered by Paco Ignacio Taibo, the author of La Doña, a 1985 biography of Ms. Félix." (https://www.nytimes.com/2002/04/09/movies/maria-felix-87-feisty-heroine-who-reigned-supreme-in-mexican-cinema-dies.html) AuroralColibri (talk) 23:26, 10 April 2018 (UTC)

I've added the NYT date, and deprecated the data.bnf.fr date ... I think we have to keep both, as we have a source making a claim. --Tagishsimon (talk) 00:13, 11 April 2018 (UTC)
I just notified BnF for correction
next time, you can do it yoursel by clicking the "Signaler une erreur sur cette notice" link on the person's record http://catalogue.bnf.fr/ark:/12148/cb14046928v (with source, of course) -- they will send you notice when they fix it :) --Hsarrazin (talk) 08:27, 16 April 2018 (UTC)

REST API format for wikidataEdit

I'm playing with the REST API for wikidata. The returned results for an item in html form (like http://www.wikidata.org/api/rest_v1/page/html/Q42) just seem to be a dump of the JSON data associated with the item. I presume if people wanted this, they would go to e.g. https://www.wikidata.org/wiki/Special:EntityData/Q42.json. I wonder if, like the wikipedia REST pages (e.g. https://en.wikipedia.org/api/rest_v1/page/html/Albert_Einstein), the data could be arranged in a neater, HTML-like way, perhaps even something like the tabular format seen on a normal "editing" page (i.e. https://www.wikidata.org/wiki/Q42), or perhaps with section headers and breaks inserted. HYanWong (talk) 14:48, 12 April 2018 (UTC)

You should probably talk to those who maintain this API. I'm not sure who is responsible, though. Matěj Suchánek (talk) 13:26, 14 April 2018 (UTC)
I'll try posting a feature request on Phabricator. Thanks! (edit: just done so at https://phabricator.wikimedia.org/T192687) HYanWong (talk) 20:35, 20 April 2018 (UTC)

Is there way to see real "related changes" with certain propertyEdit

There is "related changes" link (like this). This link shows "edit on label", "edit on description", "addition of sitelink" and so on. Is there way to see only "edits on P1323 value". I want to see such changes for maintenance purpose, if it's possible. --Was a bee (talk) 10:35, 13 April 2018 (UTC)

@Was a bee: User:Yair rand/DiffLists.js allows filtering changes by property, which can be used in conjunction with Special:RelatedChanges to do this. Demo: Recent additions and changes for P1323. --Yair rand (talk) 02:50, 16 April 2018 (UTC)
@Yair rand: Wow, this is what exactly I hoped. Although currently not fully working (interface is shown, filtering doesn't happen), I wait implementation of this functionalities through T121361. Thanks a lot! --Was a bee (talk) 21:37, 16 April 2018 (UTC)
@Was a bee: Ah, I forgot to mention that it doesn't work unless "Hide the improved version of Recent Changes" is checked in Special:Preferences#mw-prefsection-rc. --Yair rand (talk) 22:35, 16 April 2018 (UTC)
@Yair rand: Oh, after resetting preference, it worked!. Although mysteriously filtering doesn't work in watchlist and recent changes, it works in history and contribution page. Hmm, this is interesting software. Thanks for let me know!--Was a bee (talk) 20:40, 18 April 2018 (UTC)

Updating Wikidata:List of propertiesEdit

Since all of our old lists of properties are outdated, I would like to replace Wikidata:List of properties with a new User:Micru/Wikidata:List of properties.

Could you please take a look and voice your opinion? Thanks! --Micru (talk) 20:00, 13 April 2018 (UTC)

  • Hi, I would agree that we need better ways to explore and visualize properties, and your proposal goes into the right direction. However, some of the tools you are listing are by far not mature (yet). For example, it should definitely be possible to filter out all the identifier properties - in fact they should be explorable separately from the other properties. Also, some of the standard queries of the tools you are referencing run into time-out issues (at least when run from the Mozilla Browser, which has a lower performance on the SPARQL service than for example Google Chrome). Cheers. --Beat Estermann (talk) 09:48, 15 April 2018 (UTC)
@Beat Estermann: Prop explorer has been updated and now you can filter out all the identifier properties, and you can explore them independently if you wish, just select the type of property that you want to show. If you tell me which tools give you problems I can either contact the tool creators or add a notice with the potential issues. So do you think the proposed page is now ready to be used as default? --Micru (talk) 07:35, 16 April 2018 (UTC)

Wikidata GamesEdit

Are any of the Wikidata games working for anyone? I've tried two browsers, and various gales, and they're not for me (and I know Magnus is busy elsewhere). for example https://tools.wmflabs.org/wikidata-game/distributed/#game=9 hangs in Firefox and gives an unspecified error in Opera. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:08, 13 April 2018 (UTC)

Game Mode from Mix'n'Match (https://tools.wmflabs.org/mix-n-match/#/random/299) works for me. The Distributed Game (your example link https://tools.wmflabs.org/wikidata-game/distributed/#game=9) hangs. I am using Chrome + Windows 10. - PKM (talk) 21:48, 13 April 2018 (UTC)
Does not work for me, there seems to a problem in the tool that provides suggestion for the game. Matěj Suchánek (talk) 13:25, 14 April 2018 (UTC)
The "error" was that you had played through all' of the tiles (~8400) I had created back in the day. The update function was still using WDQ, which has been deactivated quite a while ago, so no new candidates. I patched it up a bit, running now. Should already work again. --Magnus Manske (talk) 08:32, 16 April 2018 (UTC)
https://tools.wmflabs.org/wikidata-game/ certainly stopped working for me months ago : impossible to get a suggestion. waiting forever.
pity because it was very useful to match people and gender quickly :( --Hsarrazin (talk) 08:47, 16 April 2018 (UTC)

Property "Time of the day" by using 1440 itemsEdit

Since the use case of "time of the day" is different than the use case of "duration in HH:MM:SS", I was wondering if we could create a property "time of the day" with data type item which takes as value one of 1440 items (24h * 60min), each one labeled as "00:00", "00:01", "00:02", and so on. Would it make sense? Are there any use cases?

For opening hours I suppose we would need a property "open on" with item values "Monday", "Tuesday", etc. and qualifiers "start time of the day" and "end time of the day".

Thoughts? --Micru (talk) 21:14, 13 April 2018 (UTC)

I'm also thinking that perhaps there is no need to create so many items, as normally the only items used would be for hours, or half-hours, perhaps quarters in some rare occasions. In that case only 96 items (4*24) would be necessary to have the most used times 0h, 0:15, 0:30, 0:45, and so on. --Micru (talk) 10:36, 15 April 2018 (UTC)

Synalpheus pinkfloydi (Q29367343) and Synalpheus pinkfloydi sp. nov., a new pistol shrimp from the tropical eastern Pacific (Decapoda: Alpheidae). (Q29390847)Edit

To keep track of this ongoing dispute with Mr. Mabbett:

  1. In Synalpheus pinkfloydi (Q29367343) he readded a constraint violation.
  2. In Synalpheus pinkfloydi sp. nov., a new pistol shrimp from the tropical eastern Pacific (Decapoda: Alpheidae). (Q29390847) he removed heavily used statements.

Any idea what could be done? --Succu (talk) 21:16, 13 April 2018 (UTC)

Bad constraints should be removed fixed. I didn't remove anything from the latter item. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:27, 13 April 2018 (UTC)
Of course you removed statements. Why is the constraint bad? --Succu (talk) 21:30, 13 April 2018 (UTC)
The constraint is bad for the reasons explained, at length, on Wikidata:Project chat/Archive/2017/07#Editwar at Desmopachria barackobamai (Q30434384) and especially its 'named after' sub-section; see the 'Kentish Plover' example therein. Anyone can see that I removed nothing in these edits, but feel free to explain what you believe I did. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:37, 13 April 2018 (UTC)
The widly used statment volume (P478) in Synalpheus pinkfloydi sp. nov., a new pistol shrimp from the tropical eastern Pacific (Decapoda: Alpheidae). (Q29390847) was removed by you. Once again: Why is the constraint bad? Feel free to summarize your arguments for everybody here. Danke. --Succu (talk)
Nope; despite your selective quoting of one diff in a run of several, the volume, 4254, is still shown, quite clearly, on that item. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:10, 13 April 2018 (UTC)
  1. So once again you can't.
  2. Ouf of 12227 atricles we have for Zootaxa (Q220370), only one is lacking the statements you removed.
--Succu (talk) 05:43, 14 April 2018 (UTC)
@User:Rschen7754, am I allowed to restore the correct values? --Succu (talk) 20:45, 15 April 2018 (UTC)
If there is a disagreement between you two, ask others for comment. --Rschen7754 20:56, 15 April 2018 (UTC)
I asked you, User:Rschen7754 as a blocking admin. --Succu (talk) 21:03, 15 April 2018 (UTC)
I have done so; more than once. You'll note, for example, that user:ChristianKl said: "Items can have different names in different languages and also multiple names in the same language. "Named after" is a property of a specific name of an item and therefore I agree that it makes more sense as a qualifier.". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:17, 15 April 2018 (UTC)
As if Andy Mabbett is going to be stopped by a consensus ... - Brya (talk) 04:03, 21 April 2018 (UTC)

I have similarly restored the named after (P138) qualifier on Myrmoteras mcarthuri (Q13871073), which was changed with no explanation and no discussion. My reasons for doing so are as explained Wikidata:Project chat/Archive/2017/07#named after. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:04, 15 April 2018 (UTC)

To cite you: „This still requires a resolution”, but you didn't help to resolve issue #1. --Succu (talk) 21:30, 15 April 2018 (UTC)
I did; I pointed out that "Bad constraints should be fixed". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:11, 15 April 2018 (UTC)
In the thread I cited: no! And reciting yourself again and again without providing a new perspective is useless. --Succu (talk)

Any idea what could be done? --Succu (talk) 21:06, 17 April 2018 (UTC)

Please note this related confusion about Revision of the Neotropical water scavenger beetle genus Quadriops Hansen, 1999 (Coleoptera, Hydrophilidae, Acidocerinae). (Q42255057). --Succu (talk) 21:12, 18 April 2018 (UTC)

Help, PetScanEdit

Hi. I wanna know why I'm not getting labels in Spanish with this petscan-query. strakhov (talk) 21:34, 13 April 2018 (UTC)

I think it's Topic:Ub9l5yd1u0m8t92q. --Edgars2007 (talk) 16:27, 14 April 2018 (UTC)
Thanks! Well, I'll wait to see what happens. :) strakhov (talk) 17:30, 15 April 2018 (UTC)
Fixed. --Magnus Manske (talk) 09:37, 16 April 2018 (UTC)

Paper size tolerancesEdit

Can the value of height (P2048) and width (P2049) in items such as A0 (Q12062327), A1 (Q12062328) etc. also include the permissible tolerance as specified in ISO 216 (±1.5 mm for dimensions ≤ 150 mm, ±2 mm for dimensions > 150 mm and ≤ 600 mm, ±3 mm for dimensions > 600 mm)?

I would state, for instance, that A1 has height (841 ± 3) mm and width (594 ± 2) mm, but is A1 (Q12062328) specifically about the ISO size? DIN 476 used to specify slightly tighter tolerances (±1 mm, ±1.5 mm, ±2 mm) – though the part DIN 476-1 about the A and B series has been withdrawn in favor of DIN EN ISO 216, so perhaps this is obsolete – and there may be other standards with different tolerances, so should I use a qualifier (which one?) or would that be in a separate item? We already distinguish between B series (Q43305767) and JIS B series (Q43351400), but these already differ by the “ideal” sizes. -- IvanP (talk) 23:14, 13 April 2018 (UTC)

@IvanP: yes to the first question, as easily as changing the value from 1,189 to 1,189±3 such as in this (now reverted) edit. See also Help:Data_type#Quantity. I don't have a good answer for ISO vs DIN tolerance diffs; could be done as 2 items, could be done as 1 item with 2 measurements, each referencing the pertinent standard (and there may be an appropriate additional qualifier for the measurement & other claims, pointing to the standard, such as of (P642)?). --Tagishsimon (talk) 23:20, 13 April 2018 (UTC)
Regarding the qualifier, I would not use statement supported by (P3680) since the standard defines the tolerances rather than just supporting the statement that they were set this way. I am unsure about criterion used (P1013); I would use it to make clear which measure is meant exactly (e.g., height (P2048) (which height?) → height to pinnacle (Q26970842)), but in this case, the purpose is to make clear what kind of paper size is meant (namely, A0/A1/… as defined in ISO 216). Is of (P642) the way to go? Would love opinions. -- IvanP (talk) 09:03, 14 April 2018 (UTC)
I suggest creating two items both with label "A1", and a description noting which item is for the ISO variant, and which item is for the DIN variant of the paper size specification. Then use stated in (P248) in references on each item, pointing to the specific ISO or DIN standard. Values of properties such as height (P2048) and width (P2049) would therefore be different on each of the two items due to the variance in tolerances allowed. I would also suggest a third item with label "A1" that is a disambiguation/class item, with the ISO and DIN items being instances of this item. Properties such as height (P2048) and width (P2049) would not be appropriate to use on this third item. Dhx1 (talk) 12:28, 15 April 2018 (UTC)
@Dhx1 Ah, stated in (P248)! I am not happy with of (P642) either, because I would use it in relation to a property value, e.g., position held (P39) maire (Q382617) (of (P642) Rochefourchat (Q323644)), which would mean maire of Rochefourchat. In our case, we have a name which may have multiple meanings. In the end of May, Wikidata should support Lexemes for lexicographical data, but this is not quite what we need here, since we want to describe the name language-independent. Should we make a disambiguation item for kilobyte, megabyte etc. as well, then? conversion to standard unit (P2442) currently has two values in terabyte (Q79741), 1,000,000,000,000 byte and 1,099,511,627,776 byte. The first one concerns the decimal terabyte, the second one the binary terabyte (tebibyte). We already have, e.g., quintillion (Q41650359) for the number name, where it says facet of (P1269) 10^30 (Q3115521) (valid in place (P3005) long scale (Q19202121)) and facet of (P1269) 10^18 (Q319582) (valid in place (P3005) short scale (Q19202120)). However, the long and short scale are not geographical objects (cf. value type constraint!). (@Bigbossfarin) Besides, what to do about sitelinks? The German Wikipedia article Quintillion does mention the short-scale value, but its topic is really the long-scale value, conforming to the meaning of the name in German. The article says:
Die Bezeichnung ist nicht identisch mit quintillion im US-amerikanischen Englisch, das unserer Trillion (1018) entspricht.
The denotation is not identical to quintillion in US-American English, which corresponds to our trillion (1018).
So should the article be linked in quintillion (Q41650359) – as it is now – or rather 10^30 (Q3115521)? In contrast, the Kazakh article Квинтиллион is linked in 10^30 (Q3115521), but is actually about the short-scale value (10^18 (Q319582)), while also mentioning the long-scale one (it says something like [I do not speak Kazakh]: “Quintillion – a one followed by 18 zeros, i.e., 1018. In some countries, a quintillion is 1030.”). I have no concerns with the English article Billion being linked in billion (Q41650356), though. -- IvanP (talk) 12:26, 21 April 2018 (UTC)
Hi, I was correcting the mistake with Квинтиллион. I would propose to replace valid in place (P3005) by applies to part (P518) in number names, any other opinions? Sitelinks about numbers & names have to be checked individually what it belongs to sooner. In the case of Quintillion I would say it is more confortable for reeders & editors as it is right now. Greetings Bigbossfarin (talk) 12:47, 21 April 2018 (UTC)
@Bigbossfarin The long/short scale is not really a part of the name quintillion, it is a system which gives the name a meaning. Maybe we need a new property … “In the case of Quintillion I would say it is more confortable for reeders & editors as it is right now.” – Should we not go by the subject item rather than the name? For instance, kerosene (Q76904) has a sitelink to the German article Petroleum rather than Kerosin. -- IvanP (talk) 14:37, 21 April 2018 (UTC)

What property is best to use for a "seat number" qualifier?Edit

Is there any property that could be used as "seat number" to be used as a qualifier for the property member of (P463) (and maybe position held (P39))? I want to put that as a qualifier for the statement that a human (Q5) is member of (P463) of Swedish Academy (Q207360). Swedish Academy (Q207360) has 18 distinct "seats" numbered from 1 to 18, and I want to be able to make a query listing all persons that have been the "holder" of a specific "seat", e.g. seat number 7. The same could be used for various parliaments that have numbered individual seats. I guess a possibility is to create 18 separate objects, one per specific "seat", but such a scheme may not be feasible for parliaments with maybe hundreds of individual seats. So I would prefer to use a qualifier.

None of the properties in the following list seems to be a perfect choice, so I would appreciate a recommendation on what to use as "seat number" qualifier.

--Larske (talk) 09:23, 14 April 2018 (UTC)

It seems noone has a recommendation on what property to use as a qualifier for "seat number" to be used in a claim of member of (P463) a parliament like entity with individual and numbered seats. I will use series ordinal (P1545) then. --Larske (talk) 10:58, 21 April 2018 (UTC)

Records and record progressionsEdit

On the one hand, the English-language Wikipedia has an article called Flight airspeed record, on the other hand, it has an article called Men's pole vault world record progression.

Now two examples are given for record held (P1000), Renaud Lavillenie (Q1742)men's pole vault world record (Q1136293) and Augustus Orlebar (Q4821509)flight airspeed record (Q1038621), but one cannot say that Lavillenie holds the men's pole vault world record progression. What to do about this, changing the Wikidata label into men's pole vault world record but leaving the Wikipedia article linked to it? Note that the French label is record du monde du saut à la perche (OK) and the German label is Stabhochsprungweltrekorde der Männer (plural!).

I am also uncontent with the use of the property record held (P1000) in the item 100 metres (Q164761). It is not like Usain Bolt is a record held by the 100 metres race; rather, the record for the fastest 100 metres race is held by Usain Bolt. -- IvanP (talk) 15:12, 14 April 2018 (UTC)

men's pole vault world record (Q1136293) actually seems like the better target, because it's an item for a subclass of world records, unlike flight airspeed record (Q1038621) which is an item for a Wikimedia list article. I think it would be OK to change the label. record held (P1000) in 100 metres (Q164761) is just backwards. Ghouston (talk) 03:56, 15 April 2018 (UTC)

Refound dateEdit

We are using inception (P571) and dissolved, abolished or demolished (P576) for a team foundation date and dissolved date. But, what we do if a team refounded after dissolved? Two different questions I have.

1) We put the refounded date at P571, as a second value? But, it has the constraint single value constraint (Q19474404). How can we show that the team was refounded a specific date?

2) We made P576 value a deprecated rank? (sorry for my English)

3) If the team dissolved again? P756 has the constraint single value constraint (Q19474404).

My example,

Pezoporikos Larnaca FC (Q2277220) founded at 1924, then dissolved at 1932 (merged with other team, created a new team), then refounded at 1937 and then dissolved at 1994 (merged with other team). For other teams, they just dissolved (not by merging) and refounded some years later.

Xaris333 (talk) 22:37, 14 April 2018 (UTC)

I'd say first decide whether the refounding is genuinely the same team, and not a new team with the same name. The same thing also happens with other types of organization like political parties and companies. If it a continuation, then I suppose you'd use inception (P571) for the first founding date, and dissolved, abolished or demolished (P576) for the final dissolved date, with periods of inactivity not recorded in that way. Ghouston (talk) 23:14, 14 April 2018 (UTC)
Its the same team... Ok, but with your way we lose informations. There is a time in period that the team, political party, company, didn't exist. Xaris333 (talk) 23:51, 14 April 2018 (UTC)
Because that first time it dissolved it wasn't a true dissolution, because it continued at a later period. And the refounding isn't a true foundation since it existed previously. Ghouston (talk) 03:32, 15 April 2018 (UTC)
But how can we show that the team, political party, company didn't exist for some years? That period, the dissolution was true. Xaris333 (talk) 04:18, 15 April 2018 (UTC)
Maybe with significant event (P793) with dissolved, abolished or demolished date (Q29933798) and point in time (Q186408), although this seems confusing. There don't seem to be items for start and end of a period of inactivity, or temporary cessation / restart. Ghouston (talk) 07:16, 15 April 2018 (UTC)
Quite a few such examples can be found by searching for "refounding" in Wikipedia. A lot of them seem to be sports teams, but Saxony-Anhalt (Q1206) is also a good example. Perhaps defining a couple of new items to be used with significant event (P793) would handle it? Ghouston (talk) 07:30, 15 April 2018 (UTC)
Identity is strongly associated to the temporal continuity of existence, which is delimited by a start date and an end date. If something ceases to exist, that will never exist again nor will be recreated, and a future entity with the same name should be considered a different entity. So I would create several entities in Wikidata, since I also consider them different entities in the real world. --abián 13:25, 15 April 2018 (UTC)
Wikidata doesn't really have the privilege of deciding such things: it's determined by whether the entity has multiple Wikipedia entries or a single entry. Perhaps a case will turn up that has multiple entries in one language and a singe entry in another. In reality its messy: there are likely to be aspects in which the entity acts as a continuation (beyond just the name, such as having some of the same people involved) and aspects in which it acts as a new entity (such as a new legal registration.) Did China become a new state in 1949 when it became the People's Republic of China (Q148), or is was it a continuation of the same state with a new government and new name? We have People's Republic of China (Q148) founded in 1949. Ghouston (talk) 23:39, 15 April 2018 (UTC)

Translating "Motivation"Edit

Currently, property proposals have the string "Discussion" translated, by inputting {{int:Talk}} which outputs "Discussion". It would be useful to have the header "Motivation" also internationalized. The preloaded property proposal template would also need to be updated. NMaia (talk) 13:18, 15 April 2018 (UTC)

instance of:list and P279Edit

Somehow subclass of (P279) doesn't work well on items for lists. That is items with instance of (P31)=Wikimedia list article (Q13406463).

There are some on Wikidata:WikiProject Lists/reports/P279 cleanup. It includes:

  • 1. Items with labels = "list of" and a subclass that is also labeled "list of"
  • 2. Items with labels = "list of" and a subclass that is not labeled "list of"
  • 3. Items with labels in plural (other than "list of") and a subclass that is not labeled "list of"
  • 4. Items with labels in singular (other than "list of") and a subclass that is not labeled "list of"

What to do?

  • For (4), the solution would probably be to remove p31=Wikimedia list article (Q13406463).
  • Maybe for (3) as well.
  • For 1 and 2, the value of P279 should probably be moved to another property.
    --- Jura 16:34, 15 April 2018 (UTC)

Commons Cultural heritage monuments with known IDsEdit

Hi guys,

The question is simple, there's some effort to make this: Category:Cultural heritage monuments with known IDs some how useful here, there's some integration possible to both worlds? Rodrigo Tetsuo Argenton (talk) 20:04, 15 April 2018 (UTC)

@Rodrigo Tetsuo Argenton: Sorry, I don't understand your question. Can you please rephrase it? You're probably interested in Wikidata:WikiProject WLM. Multichill (talk) 21:17, 15 April 2018 (UTC)
@Multichill:, if there is any kind of integration between the categories/templates at Wikimedia Commons and here. We have there a number to identify the monument, maybe we could use some how here. Because, we have there thousands of images identified, and as we categorised it by template, we could simply change the templates and created a bridge there easily by bot, not manually as now.
Rodrigo Tetsuo Argenton (talk) 21:48, 15 April 2018 (UTC)
@Rodrigo Tetsuo Argenton: If the ID template is being used in categories, then it would be good to migrate the info to here (if not already here) and we can use commons:Template:Wikidata Infobox to show it there. For files, a lot of the work will become easier once structured commons is here, but for IDs that are present both here and there then we could try to match them up, and add image (P18) here, and "wikidata=" tags there. Thanks. Mike Peel (talk) 11:51, 16 April 2018 (UTC)
@Rodrigo Tetsuo Argenton, Mike Peel: before you start doing double work:
The monuments database indexes about 1,5 million monuments (stats). A lot of these id's are cross referenced with Wikidata already or that can easily be done. The monuments database used to index images too, last time it ran it was about 2,6 million images (more info). I haven't invested any time yet on removing the intermediate step. To explain that, now it's file -> id, id -> Wikidata, that could be file -> Wikidata. The reason I haven't done anything yet is Structured Data on Wikimedia Commons. This is a good set to convert once we have the initial release of that deployed. It's a bit of double work to add Wikidata id's now in template pseudo structured data and doing everything again a bit later.
I would wait a bit and in the meantime focus on improving items with heritage designation (P1435) and making sure all the items about monuments have at least one of these properties. Also the cross referencing effort probably could use a hand, but I don't know the latest status. Multichill (talk) 16:23, 16 April 2018 (UTC)
@Multichill: For files, I'd agree, better to wait for structured commons (although the latest changes to commons:Template:Artwork to auto-fetch info from Wikidata when given the qid are a huge step forward). For categories, structured commons won't impact those, so moving the IDs in those over sooner rather than later makes more sense. Thanks. Mike Peel (talk) 18:12, 16 April 2018 (UTC)
  • Maybe you could use it to connect categories to Wikidata items.
    --- Jura 18:15, 16 April 2018 (UTC)
    • That’s probably quite easy and already done, but I’ll have a look anyway and see if new links can be made. Multichill (talk) 12:47, 18 April 2018 (UTC)

Phoenician languageEdit

I would like to add a statement that the name of Gades (Q3094251) was 'Gadir' in Phoenician (Q36734), but 'Phoenician' isn't available in the language drop-down. Phoenician has ISO 639-2 code 'phn'. What needs to happen to make Phoenician a valid language for <name> statements? - PKM (talk) 21:54, 15 April 2018 (UTC)

@PKM: You should be subscribed to the ticket now. Mahir256 (talk) 23:18, 15 April 2018 (UTC)
@PKM: but please don't forget that Phoenician (Q36734) had no such letters as "G", "a", "d", "i" or "r". Infovarius (talk) 16:51, 18 April 2018 (UTC)
It's hard to reconcile that with statements like "Phoenician gadir ‘masonry wall enclosing a town’." (Oxford Concise Dictionary of Place-Names, under 'Agadir (Morrocco)'). Perhaps different romanizations? I have a handful of sources that call the Phoebnician city 'Gadir'. If you have sources that indicate a different name, it would be great to add both to the item. - PKM (talk) 18:37, 18 April 2018 (UTC)
I agree that Gadir is a valid Phoenician word. It can be rendered in different scripts and above is rendered in Latin (romanization). If you consult the IANA lang tag list, you'll see the default script for this language is "Phnx" Phoenician, therefore the language should be called "Phoenician (Latin transcription)" and the lang tag should be as in "gadir"@phn-Latn --Vladimir Alexiev (talk) 13:15, 19 April 2018 (UTC)
Looks like langcom overlooked that. Wonder what they are actually checking/discussing.
--- Jura 13:31, 19 April 2018 (UTC)

about project tigerEdit

how can i be a perticipent of this competition? should i only need to log in by my wiki account and edit pages? or do i need to do things first?

@Mahmudul hasan topu: (Whenever you write a message on this page or any other talk page, please sign your posts using four tildes—like "~~~~", but without any quotation marks or <nowiki> tags around it.) At present Wikidata is not within the scope of the Project Tiger Editathon. You may wish to find out more here. Mahir256 (talk) 16:18, 16 April 2018 (UTC)

Why numbers are in English format only?Edit

Hello, I was trying to add wikidata data in sawiki infoboxes, but all the output (numerical) is in english numbers. For example see 476 and 13 June 1992 on sawiki. All the text output is in local language, so should the numerical one be. I raised this issue at enwiki and was informed that this is due to wikidata in this comment. Can anyone please help me on this? Capankajsmilyo (talk) 13:21, 16 April 2018 (UTC)

The Wikidata module should handle the localization itself by calling frame:callParserFunction to substitute {{#time: }}, which works well on your wiki. Matěj Suchánek (talk) 14:52, 18 April 2018 (UTC)
It's not generally good coding practice to use parserfunctions for things that can be implemented in Lua. Pppery (talk) 02:54, 19 April 2018 (UTC)
Not doing so in case of localization, which is already well covered in MediaWiki, is just reinventing the wheel. Matěj Suchánek (talk) 07:19, 19 April 2018 (UTC)
We don't require extra code for text values, who do we need it for numerical ones? Capankajsmilyo (talk) 11:43, 19 April 2018 (UTC)

Wikidata weekly summary #308Edit

defining formula (P2534)Edit

Is   really a defining formula for monoid (Q208237)?   (from semigroup (Q207348)) is at least an equation, but   is not a notation specifically for a semigroup, rather, it can be used to define what a semigroup is by saying that   is a semigroup iff   is an associative operation and   is a set closed under  .

Furthermore, has quality (P1552) currently has two values in monoid (Q208237), identity element (Q185813) and associativity (Q177251). I am fine with identity element (Q185813) – there are monoids with different identity elements –, but think that associativity (Q177251) is inappropriate. -- IvanP (talk) 18:57, 16 April 2018 (UTC)

@IvanP: On defining formula, a lot of these were imported wholesale from enwiki in a careless manner, and I've deleted hundreds that were just inappropriate. However the two you mention were added more recently by @Bigbossfarin: - might be something else going on here? ArthurPSmith (talk) 12:37, 17 April 2018 (UTC)
Hi, I was importing the formula from de-wiki. In this sense a monoid (Q208237) is defined as a triple (Q20088882)  , where   is a set (Q36161),   is a associative internal binary operation (Q47407371) on   and   a identity element (Q185813) in  . The input box is simply to short to get all this information in it. Maybe   would be an improvement? And I agree with you that associativity (Q177251) is very inaccurate. --Bigbossfarin (talk) 13:30, 17 April 2018 (UTC)

Standardizing historic patents, post #2Edit

We could start to standardize on an ontology for pre-1920 patents, as I mentioned in a Project Chat post a week ago. Interest was limited. And yet I would like to create a Wikidata WikiProject for this topic, analogous to the ones for companies, organizations, universities, and occupations. Any objections? Or advice?

I'd like to get started now. In two weeks I have a meeting with specialists at WIPO, the UN organization that manages modern-day patent rights, and would like to get their support or a wise critique of the effort. Some of their data could be uploaded eventually, and on the wiki side we might be able to set up automatic links analogous to the authority control templates so as to get immediately from a Wikipedia article about an individual to their patent documents across countries, a service not offered very well elsewhere for historic patents. Modern patents are conceptually the same, but they refer to intellectual property rights that may still be relevant, or maybe they might be copyrighted, and they are longer and more difficult to read, AND there are more services designed to manage that sort of information which might be technologically relevant now. Therefore I think it is reasonable to start with the older ones. -- econterms (talk) 22:53, 16 April 2018 (UTC)

Go ahead and start the wikiproject, at least some of those in the other ones you link are probably interested. Is there any particular reason historic patents would be different from modern patents in terms of data structure/ontology? ArthurPSmith (talk) 12:32, 17 April 2018 (UTC)
Thanks kindly, ArthurPSmith! I will start it. Historic patents can be a little different. (1) They may have been issued by governments that do not now exist, and therefore do not have standard two-letter codes. E.g. Austro-Hungarian Empire, and the German and Italian states that existed before those nations unified to their current form. (2) Before legal standardization there might be more variation in the data in them although I have not noticed much of this. But the earliest ones did not always refer to technologies or inventions but to monopolies granted, e.g. by the British crown, or monopolies on the rights to import some particular kind of thing. (3) they had different term lengths from the modern standard. This is not a long list but if we dig there would be more. -- econterms (talk) 13:22, 20 April 2018 (UTC)
Also, for old patents, we can be sure they are not copyrighted any more and that they have no intellectual property traction any more ; that is, they do not represent legally relevant claims any more so we could treat them a little more informally. -- econterms (talk) 17:48, 20 April 2018 (UTC)

Dye plantsEdit

Do people prefer Reseda luteola (Q157927) <instance of> dye plant (Q907341) or Reseda luteola (Q157927) <use> dye plant (Q907341)? I prefer <instance of> but not enough to argue about it if others disagree, as long as we're consistent. There are only two instances so far, so I can change them easily if that's the consensus. - PKM (talk) 22:56, 16 April 2018 (UTC)

Or perhaps <subclass of> dye plant (Q907341)? - PKM (talk) 23:07, 16 April 2018 (UTC)
Instance or subclass. dye plant (Q907341) has a description "plant from which a dye can be extracted" and a use (P366) with the value dyeing (Q1164991). I could do with more guidance on instance versus subclass; it's not always clear to me which is appropriate. --Tagishsimon (talk) 23:11, 16 April 2018 (UTC)
An individual plant would be an instance, Reseda luteola (Q157927) is a class of many plants. Ghouston (talk) 01:12, 17 April 2018 (UTC)
I think generally it's not a good idea to go overboard with subclassing. It's nice that all humans are instances of the same item (even if that item is somewhat screwed up.) I think I'd just make each species a subclass of its parent taxon and identify its characteristics with other properties. Ghouston (talk) 01:20, 17 April 2018 (UTC)

2 yearsEdit

Dear administrators,

Mr Javier Gomá (https://www.wikidata.org/wiki/Q6165536) was hired by the Juan March Foundation in 1996. In 2003, he was named executive director. How can I express it in Wikidata? I am not able to put 2 years.

Regards.

Soleil222 (talk) 08:24, 17 April 2018 (UTC)

I think you have to add the employer twice, and only once with "position held" with the 2003 date. --Anvilaquarius (talk) 08:28, 17 April 2018 (UTC)

Translation not updatedEdit

Can someone tell me why this translation has not been yet replicated to MediaWiki:Valueview-expertextender-languageselector-label/ca? I translated it last december. Thanks, Paucabot (talk) 14:47, 17 April 2018 (UTC)

@Paucabot: the translation was imported correctly (Gerrit change Idd2f67762d), but that message is not directly part of Wikibase (the MediaWiki extension that powers Wikidata), but of a library which Wikibase uses. Wikibase imports the latest released version of that library, and we haven’t released a new version of it since November, so all translation changes since then aren’t effective on Wikidata yet. We’ll try to get this fixed, it should be deployed either tomorrow or next Wednesday. Thanks for translating, and for bringing this to our attention! --Lucas Werkmeister (WMDE) (talk) 16:17, 17 April 2018 (UTC)

P31=Norse humanEdit

When working on property:P2600 I found that one item is instanceOf Norse human Q24451723. There are many more humans linked via P31 Special:WhatLinksHere/Q24451723. Is this desired? 78.55.76.113 18:43, 17 April 2018 (UTC)

I don't think Norse human (Q24451723) is needed or desirable, it can be done with ethnic group (P172) Norsemen (Q1211290). Subclassing humans would lead to the madness that is Commons categories and intersection categories, since humans can have a lot of different characteristics. Ghouston (talk) 21:56, 17 April 2018 (UTC)
Agreed. Not desired. Looks like a one-person wikiproject - Wikidata:WikiProject Norse - intent on turning all sorts of stuff (well, runestones, humans) into Norse Runestones and Norse People. [3] [4]. @Anders Feder: For Ghouston's reasons, not a sensible way to proceed. --Tagishsimon (talk) 22:07, 17 April 2018 (UTC)
Strongly agreed. Let's get rid of this property. --Anvilaquarius (talk) 08:43, 19 April 2018 (UTC)

Fusion of Q666112 and Q39314414Edit

I tried to merge this two itens but the merger didn't let me. I thought they were the same but a user mentioned it was a recent split in the historic of one of the items, so I'm no longer sure about it. Can someone explain me what is the criteria here and/or sort this mess? - Sarilho1 (talk) 20:52, 17 April 2018 (UTC)

You are trying to merge a Latin script name with a Cyrillic script name, they are different. Sjoerd de Bruin (talk) 21:01, 17 April 2018 (UTC)
Oh, thanks. I thought that the script didn't matter. Good to know, then. Are the interwikis then handled as different articles? - Sarilho1 (talk) 21:40, 17 April 2018 (UTC)
Interwikis are handled as separate. Seems like a very poor solution. --Tagishsimon (talk) 21:55, 17 April 2018 (UTC)
Interwikis are handled "directly" as separate. But from a wp, it is very possible to use a lua template to link all said to be the same as (P460) items.
this solution was chosen, after many discussions, by the Project Names, to avoid the preeminence of english language on others, and to avoid also that latin-alphabet would be the center of the system. This way, if a person is Russian, he will use Борис, and if the person was british, he will use Boris. It is the same for hebrew names, chinese, japanese, korean names, etc... There are still a lot of past errors to clean up, but this is the idea.
for more info on that, you may want to read the discussions on Wikidata:WikiProject_Names, and even participate there :)
@Harmonia Amanda: who may explain it better than me...--Hsarrazin (talk) 09:15, 18 April 2018 (UTC)
@Tagishsimon, Hsarrazin: Maybe this is the again another reason that every Wikidata users should support the way to fix Incubator sites' support: Drop the unfair "one sitelink per one wiki" limitation. --Liuxinyu970226 (talk) 10:57, 18 April 2018 (UTC)

Enwiki RFC raises concernsEdit

There's a discussion going on enwiki related to wikidata at en:Wikipedia:Wikidata/2018 Infobox RfC.

  • Some editors have pointed out that editors on Wikidata can change the sourced info with incorrect one. How does Wikidata implement check on that?
  • Another concern raised is the spamming by humans and bots on Wikidata. How is that kept under check here?

Capankajsmilyo (talk) 04:56, 18 April 2018 (UTC)

Re monitoring changes to sourced statements: Wikidata_talk:Abuse_filter#Tag_changes_to_sourced_statements. --Yair rand (talk) 06:11, 18 April 2018 (UTC)
This concern has & will continue to be be raised every 4 months or so on language wikipedias, until watchlists / histories on language wikipedias are able to show changes to the article arising out of changes in wikidata. Is there a Phab ticket for that? fwiw, my experience of screwing up quickstatement runs is that I get an angry wikidata person knocking on my talk page within minutes, so in that respect we work like language wikipedias: people watch items and bark when idiots like me bork them. --Tagishsimon (talk) 12:28, 18 April 2018 (UTC)
Wikipedia watchlist integration has already improved a lot, it might be worth to test it again. As far as I know it is not yet complete and there are some issues to resolve (e.g. delayed integration sometimes), but the amount and quality of listed edits are meanwhile pretty good. —MisterSynergy (talk) 12:51, 18 April 2018 (UTC)
I don't know which watchlist are you talking about. The one I just tested was flooded with "linked to this/that language" and "removed from this/that language". That's definitely NOT what enwiki editors want. Capankajsmilyo (talk) 11:41, 19 April 2018 (UTC)
I talk about the Wikidata integration in the standard watchlist (activated by the “Show Wikidata edits in your watchlist” checkbox at en:Special:Preferences#mw-prefsection-watchlist). On my 8000+ article enwiki watchlist, I see 10 Wikidata edits out of the past 250 edits which are listed. This is a typical load these days at enwiki, and numbers at my (smaller) dewiki watchlist are very similar. If you refer to interwikilinks: whose were shown in the pre-Wikidata time as regular edits as well, and many editors do indeed care for them as they are listed next to the article. —MisterSynergy (talk) 11:59, 19 April 2018 (UTC)
I didn't actually know watchlist integration was as good as it is (having turned it on). Maybe language wikis need to think about turning wikidata changes on by default? But I still see nothing in page histories. --Tagishsimon (talk) 21:25, 19 April 2018 (UTC)


Perhaps one remark:
One main concern is that WD allows the modification of a value of a statement without any care about the linked source. If a vandal change a value of sourced statement, then the argument that WD data can be filtered by looking only at statements with source fails. This criticism is from a contributor who develops a particular system to track modifications compared to a referenced version of the article.
So if someone changes a value of a statement, the corresponding source has to be deleted.
Then the usual criticism is that WD will be more vandalized than WPs if all WPs are using data from the source. Snipre (talk) 13:33, 19 April 2018 (UTC)
@Capankajsmilyo: For your question about spamming, can you explain us how wp:en deal with spamming in their articles ? WP contributors have always higher expectations with WD than the ones they accept for their wp. Snipre (talk) 13:37, 19 April 2018 (UTC)
Enwiki use techniques like sanctions and block of user or lock on page itself to deal with spammers. See en:Wikipedia:Spam for the guidelines. Capankajsmilyo (talk) 14:46, 19 April 2018 (UTC)
@Capankajsmilyo: Yup. Same. [5]. Wikidata is not the wild-west some language wiki users think it is. --Tagishsimon (talk) 21:25, 19 April 2018 (UTC)
@Lea Lacroix (WMDE): Can you provide us some feedback about the technical feasibility of restricting the edition of WD items to registered users only but allowing IP to contribute in talk pages and community pages ? Snipre (talk) 13:40, 19 April 2018 (UTC)
Not a chance that would be supported. Wikidata is a wiki. --Yair rand (talk) 19:53, 19 April 2018 (UTC)
@Yair rand: The registration doesn't prevent anyone to edit. We really need to balance data protective measures against contribution freedom. If WD continue to have a negative evaluation among WP contributors, this can prevent more WP contributors to contribute to WD and to use WD data in WP.
Saying that WD is a wiki is not an argument when defining requirements for contribution right: wiki doesn't mean that contributions have to be done under IP. Registration is unique, so no sense to say that requires a lot of time, registration can be anonymous, no need to provide a real identity. Why IP should be able to contribute ? Especially in WD where most of contributions are done by bots or at large scale where identification of contributors is necessary. Snipre (talk) 11:37, 20 April 2018 (UTC)
Snipre (talk) 11:37, 20 April 2018 (UTC)
There are ~27.000 IP edits per day in English Wikipedia, and 1900 IP edits per day in Wikidata (both in 2018 according to Wikiscan). Why should we allow the former, but not the latter? —MisterSynergy (talk) 11:45, 20 April 2018 (UTC)
@MisterSynergy:
  1. Because the amount of IP edits is low in WD compared to the ones of bots and registered users, so the loss won't be critical and we can expected that some IP editors will create an account to continue to contribute.
  2. Data modeling of data plays a critical role in WD and absolute respect of the data format (correct use of properties, addition of the good qualifiers, whole description of sources,...), and for that kind of work, bots are more efficient than individual contributors. IP contributors represent a high risk to add data in the wrong format leading to useless contributions due to lack of knowledge.
  3. One edit in WD can impact several dozens or even more articles in different WPs. It is necessary to have a real possibility to contact the editor when conflicting data are generated especially if the sources are not online.
  4. The registration operation is a time consuming effort for vandals compared to the effort of modifying one statement, this will discourage most vandals as it will require more actions and efforts to be able to do one vandalism.
  5. It will be more easy to track editions of vandals by using the username to revert them and once a contributor is considered as a vandal, the blocking of the account is definitive not like IP blockling due to dynamic IPs. Snipre (talk) 22:13, 20 April 2018 (UTC)

Technical feasibility is not the problem here. Instead of preventing a part of the editors to contribute, we should better continue improving the quality on Wikidata through tools to check data and sources, to patrol, to give a better overview of the data's quality. That's what the editors and the development team are already working on. Lea Lacroix (WMDE) (talk) 15:02, 21 April 2018 (UTC)

Books and AuthorsEdit

I want some opinions. I created yesterday for litteraturbanken.se a proposal link...

As it looks technical possible to have one property for both books and authors I start feeling its better to split this property into

  • Swedish_Literature_AuthorID
  • Swedish_Literature_BookID

Any comments/suggestions?

My argument is that its conceptual easier implementing two properties- Salgo60 (talk) 05:29, 18 April 2018 (UTC)

@Salgo60: Two properties are required mainly to be able to add some constraints "the item using Swedish_Literature_AuthorID has to have instance of human". Snipre (talk) 13:13, 19 April 2018 (UTC)

Model a primary source and maybe also qualityEdit

In Sweden the National archives released 100 million documents for free last month ==> we can now in WD have Primary sources like birth and death records as a source (example query)

Question: is there a best practice to model a primary source so that I can ask for

all birth dates for Swedish people not confirmed by a primary source born more than 70 years ago?

If not how do we model sources in the best way

  1. type of source e.g.primary/secondary/compiled/....
  2. quality of source
    1. High quality
      1. they have a well-documented quality system
      2. track record of delivering quality the last 10 years...
      3. by professionals mentioned as having "hallmark" quality and have very very high trustability?
    2. ???

- Salgo60 (talk) 07:30, 18 April 2018 (UTC)

located at street address (P969) vs. located on street (P669) for japanese addressEdit

I'm confused about the using of located at street address (P969) and located on street (P669). I would like to add the street address of the headquarters location headquarters location (P159) for japanese companys. For instance: 東京都杉並区阿佐谷北1-46-4 友和ビル5階

On the Property Talk Page of P969 you can read: "Use located on street (P669) and street number (P670) for multilinguage use" BUT on the Property Talk Page of P669 you can read: "In such cases [japanese addresses] you use located at street address (P969)" Now I don't know which is the right way. Any recommendation? Diggr (talk) 13:52, 18 April 2018 (UTC)

@okkn:^^--Liuxinyu970226 (talk) 14:18, 18 April 2018 (UTC)
@Diggr, Liuxinyu970226: With a very few exceptions, street names are seldom used in postal addresses in Japan. That is because most of the Japanese streets do not have their name. (see w:en:Japanese addressing system) So we can't use the pair of located on street (P669) and street number (P670) to express the address of locations in Japan. As you may know, the value type of located at street address (P969) is not item but string, so the values depend on Latin script (Q8229), Japanese writing system (Q190502), etc. I can strongly feel the importance of new system or model to represent Japanese addresses that is independent of languages. --Okkn (talk) 15:46, 18 April 2018 (UTC)

Help needed to migrate "unit symbol" from string to monolingual textEdit

unit symbol (P5061) has been created and unit symbol (string) (P558) has been deprecated. Now there is the issue of the migration of the data from one property to another. Can it be done by bot? --Micru (talk) 14:57, 18 April 2018 (UTC)

Oh, and now we should have 6000 unit symbol (P5061) in each unit?? --Infovarius (talk) 08:50, 19 April 2018 (UTC)
I undid the deprecation as it hadn't gone through a deletion request. In the meantime one was made at Wikidata:Properties_for_deletion#P2237.
--- Jura 12:54, 19 April 2018 (UTC)

Query coordsEdit

I want to create a map of all Items, having a LfDS object ID (P1708). My try is:

https://query.wikidata.org/#%23Liste%20aller%20Kulturdenkmale%20in%20Sachsen%0A%23defaultView%3AMap%0ASELECT%20%3FitemLabel%20%3FitemDescription%20%3Fimage%20%3Fcoord%20WHERE%20%7B%0A%20%20%3Fitem%20%28wdt%3AP31%29%20wd%3AQ11691318.%0A%20%20%3Fitem%20wdt%3AP17%20wd%3AQ183.%0A%20%20%3Fitem%20wdt%3AP625%20%3Fcoord.%0A%20%20OPTIONAL%20%7B%20%3Fitem%20wdt%3AP18%20%3Fimage.%20%7D%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22de%22.%20%7D%0A%7D

But it does not work, can you help me? Regards, Conny (talk) 17:28, 18 April 2018 (UTC).

@Conny: I think this would be the query:
#Liste aller Kulturdenkmale in Sachsen
#defaultView:Map
SELECT ?item ?itemLabel ?itemDescription ?id ?image ?coord WHERE {
  ?item wdt:P1708 ?id;
        wdt:P625 ?coord.
  OPTIONAL { ?item wdt:P18 ?image. }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "de". }
}
Try it! – warning: there are currently 80644 results, showing a map for them can be quite taxing for your browser. (In my case, the page hung for about 60 seconds until the map was displayed). --TweetsFactsAndQueries (talk) 17:38, 18 April 2018 (UTC)

Printing industry (Q1261092) and printing industry (Q26897133)Edit

What to do with these two?

The scope of the two German articles looks essentially the same. Could a German speaker either merge them, or distinguish them?

Alternatively, is there a distinction to be made between a broader industrial sector that includes all printing-related activities (eg ink manufacturing, book handling, etc), and the strict business of printing itself ? Jheald (talk) 18:30, 18 April 2018 (UTC)

Limit page creation and edit rateEdit

Hello all,

Following the dispatch lag problems that we encountered over these past months, we decided to set up a limit for the speed of edits and page creation. These limits are now enforced for all accounts (including bots):

  • page creation: max 40 per minute per account
  • edit: max 80 per minute per account

This means that some bots and automated tools have to reduce the speed of their edits in order to not reach these limits.

We will continue monitoring the situation carefully, and see how this has an impact on the projects. If you want to learn more about the reasons for this change, you can have a look at the ticket.

Let us know if you encouter any problem. Lea Lacroix (WMDE) (talk) 08:29, 19 April 2018 (UTC)

  • Looks like it's working: Special:Log/massmessage.
    What are the plans to develop capacity to raise it again?
    --- Jura 03:06, 20 April 2018 (UTC)
  • Doesn't seem convenient for regular editors. Didn't we have problems mainly due to bots creating new items at steady speed for several days in a row?
    --- Jura 12:31, 21 April 2018 (UTC)
    • In the past weeks, we have repeatedly seen individual edit rates up to at least 400/min, often ongoing over several hours. Apparently editors can’t overcome the temptation of starting several QuickStatements batches in parallel. (I don’t like the limitation as well, but I have no idea how to otherwise approach the problem.) —MisterSynergy (talk) 13:05, 21 April 2018 (UTC)

How to split Q6145461 in movie and book version?Edit

Yoru wa mijikashi aruke yo otome: the data here are mixed up, most of them refer to the 2017 anime movie, and a few (chinese, cantonese and japanese) to the 2006 novel book . How can I split the informations and move some of them to a new data page? --Artafinde (talk) 11:14, 19 April 2018 (UTC)

"Better source needed" ?Edit

Is there a way to indicate "better source needed" on a statement ?

For example, suppose I have a date and place of birth for somebody, from a genealogical website -- but it doesn't give primary sources. The family relationships are right, confirmed by multiple primary sources; the year of birth might be right - it matches the age given on the death certificate; though the date on the tombstone is a year earlier; and ages given on other official documents, such as census returns, immigration forms etc are all over the place; there's also a place of birth confidently stated on the genealogical website, that seems quite a long way from the family's long-term residence, but doesn't seem to have come from any other source I can see online.

The subject died in 1908, so there's no BLP issue.

I'd like to include the stated birth-place, but note that its ultimate sourcing is not clear. Is there an appropriate way to do this? On some wikis one can tag a statement with Template:Better source (Q6716717). Is there anything analogous here that one can do to mark a statement that could use better verification? Jheald (talk) 12:41, 19 April 2018 (UTC)

Found a line in an old newspaper. Turns out that the tombstone was right, the place was right, the death certificate was one year and one day out. But it would still be useful to think how to mark statements where improved sourcing is needed. Jheald (talk) 13:33, 19 April 2018 (UTC)

4 242 000 instances of human - SPARQL for Q5 externalid statisticsEdit

SELECT (COUNT(?item) AS ?count)
WHERE {?item wdt:P31/wdt:P279* wd:Q5}

Try it!

Only two Wikipedias have more than 4 million articles, namely enwiki 5.6 mio, and cebwiki 5.3 mio [6]. In the list de:Liste genealogischer Datenbanken Wikidata would be ranked 26 by number of human items.

Are there a sparql queries that could show

or even better

  • lists quantities for each externalID that is used on any instance of Q5

According to Wikidata:Database reports/List of properties/Top100 total VIAF ID (P214) = 1181059, GND ID (P227) = 606095, ISNI (P213) = 541276, BnF ID (P268) = 401272, but these numbers are not restricted to instances of Q5.

92.229.165.74 13:02, 19 April 2018 (UTC)

SELECT (COUNT(DISTINCT(?item)) AS ?count)
WHERE {
  ?item wdt:P31 wd:Q5 .
  ?item wdt:P214 [] .
}
Try it!
finds 1,018,671 distinct humans with VIAFs. (1,027,083 uses of VIAF ID (P214) on humans as a whole). Jheald (talk) 13:13, 19 April 2018 (UTC)

Jheald, thanks a lot! I did for ISNI P213 and got 476,549. The SPARQL for both on one item gives 474,573, so there are ~2000 items that have ISNI but no VIAF:

SELECT (COUNT(DISTINCT(?item)) AS ?count)
WHERE {
  ?item wdt:P31 wd:Q5 .
  ?item wdt:P213 [] .
  ?item wdt:P214 [] .
}

Try it!

Do you know how to count two properties in one query, so it should give the VIAF = 1,018,671 and ISNI = 476,549 in one run? 92.229.165.74 13:24, 19 April 2018 (UTC)

This gets close, but it counts the number of different ISNIs and VIAFs rather than the number of different humans.
SELECT (COUNT(?isni) AS ?count_isni) (COUNT(?viaf) AS ?count_viaf)
WHERE {
  ?item wdt:P31 wd:Q5 .
  OPTIONAL {
    ?item wdt:P213 ?isni .
  }
  OPTIONAL {
    ?item wdt:P214 ?viaf .
  }
}
Try it!
Note that the run time is now over 40 seconds -- the maximum allowed for a query is 60 seconds, so that may limit how much more can be built in.
It would probably be a good idea to move this thread to Wikidata:Request a query, which is a forum specifically for the writing and improving of queries. Jheald (talk) 13:38, 19 April 2018 (UTC)
Here's an attempt to count the number of actual distinct items with ISNIs and VIAFs, but it times out: tinyurl.com/ycf5g829 Jheald (talk) 13:42, 19 April 2018 (UTC)

Jheald, thanks a lot, I started : Wikidata:Request a query#SPARQL for Q5 externalid statistics 92.229.165.74 13:50, 19 April 2018 (UTC)

Help wanted on humans having ISNI but no VIAFEdit

The query shows humans that have an ISNI but no VIAF. Some are not in the VIAF DB, but those that have a GND ID or LC ID very likely are in the VIAF system.

SELECT ?item ?itemLabel ?isni ?gnd ?loc
WHERE {
  ?item wdt:P31 wd:Q5 .
  ?item wdt:P213 ?isni .
  MINUS {?item wdt:P214 [] .}
  OPTIONAL {?item wdt:P227 ?gnd.}
  OPTIONAL {?item wdt:P244 ?loc.}
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE]". }
}
ORDER BY DESC(?gnd) DESC(?loc)

Try it!

I already fixed some, but it is a lot of work. The way I did it, is to click on the ISNI and on the ISNI page click on VIAF. Or when isni.org is down, to search on viaf.org 92.229.165.74 14:15, 19 April 2018 (UTC)

Do you know the "Authority control" gadget? It may also help with this task. --Anvilaquarius (talk) 21:20, 20 April 2018 (UTC)
If if helps, this version of the query will apply the formatter URL in the query result so you don’t have to open the item page to open the links:
SELECT ?item ?itemLabel ?isni ?isniLink ?gnd ?gndLink ?loc ?locLink
WITH {
  SELECT ?item ?itemLabel ?isni ?gnd ?loc WHERE {
    ?item wdt:P31 wd:Q5 .
    ?item wdt:P213 ?isni .
    MINUS {?item wdt:P214 [] .}
    OPTIONAL {?item wdt:P227 ?gnd.}
    OPTIONAL {?item wdt:P244 ?loc.}
    SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE]". }
  }
} AS %results
WITH {
  SELECT * WHERE {
    wd:P213 wdt:P1630 ?isniFormatterUrl.
    wd:P227 wdt:P1630 ?gndFormatterUrl.
    wd:P244 wdt:P1630 ?locFormatterUrl.
  }
} AS %urls WHERE {
  INCLUDE %results.
  INCLUDE %urls.
  BIND(IRI(REPLACE(?isniFormatterUrl, "\\$1", ?isni)) AS ?isniLink)
  BIND(IRI(REPLACE(?gndFormatterUrl, "\\$1", ?gnd)) AS ?gndLink)
  BIND(IRI(REPLACE(?locFormatterUrl, "\\$1", ?loc)) AS ?locLink)
}
ORDER BY DESC(?gnd) DESC(?loc)
Try it! --TweetsFactsAndQueries (talk) 16:05, 19 April 2018 (UTC)

TweetsFactsAndQueries - Thanks a lot! It makes the process a bit faster. Interesting what can be done with WDQS. 92.229.165.74 16:35, 19 April 2018 (UTC)

CatalogEdit

Hoi, it is obvious that the use of "catalog" for projects like the "Black Lunch Table" is something that is to be phased out. These statements have qualifiers. I do not know how to do the conversion. So could someone help out and also show me how to do this? Thanks, GerardM (talk) 16:53, 19 April 2018 (UTC)

The conversion can most efficiently be done with bot code, so that no qualifier, reference, or any other detail like ranks get lost. You probably talk about a move from catalog (P972) to on focus list of Wikimedia project (P5008), right? Since this affects somewhat over 1000 items, it would take roughly 3 hours to move all of them at 6 edits per minute, a typical edit rate with the PAWS tool. This script would exactly do the move; if you want to move by yourself, log in to PAWS, start your server, create a new Python notebook, copy the code in the grey box from my linked example into the Python notebook and click “run”. It does not need any specific rights for your Wikidata account. These pages in enwiki should be updated accordingly as well, in order not to break the query functionality of the lists in BLT’s project space. —MisterSynergy (talk) 18:10, 19 April 2018 (UTC)
It is not efficient for me to learn to use a new tool. It is why I ask for it to be done. Thanks, GerardM (talk) 05:08, 20 April 2018 (UTC)
If nobody else volunteers, I can do this—hopefully this evening or otherwise tomorrow. —MisterSynergy (talk) 06:18, 20 April 2018 (UTC)
@GerardM: I just started the move. The lists at enwiki will be updated once all cases are moved. There are four lists which were broken already before the move was started, see the no items section in this Listeria status page. —MisterSynergy (talk) 10:45, 21 April 2018 (UTC)
@MisterSynergy: Thank you so much that you do this for me :). Let me know when you are done and, I will update the Listeria lists I know about. Please identify the catalogs you processed so that I can inform the people involved. Thanks, GerardM (talk) 10:58, 21 April 2018 (UTC)
As requested, this is only about the Black Lunch Table (Q28781198) “catalog”. Most or even all other cases were already moved a couple of days ago. I will ping you again once the move process has finished. —MisterSynergy (talk) 11:22, 21 April 2018 (UTC)

@GerardM: this is completed now. There are no items left to move, and I have also updated all lists in English Wikipedia (cf. en:Special:Contributions/MisterSynergy). To the best of my knowledge, none of the queries has a different result now, since I triggered updates for each one after the update. —MisterSynergy (talk) 14:23, 21 April 2018 (UTC)

Inherited valuesEdit

Some values (like "credit card length" or all has quality (P1552) values) are inerithed for all instances and subclasses of the item. Is there some way to:

  • indicate it?
  • prevent instances and subclasses of that item to be filled with different values (or at least point out when this occurs)?
  • view all values that are inherited from superclasses?

--Malore (talk) 17:00, 19 April 2018 (UTC)

Isn't it automatically the case that properties are inherited by instances or subclasses? If an instance or subclass doesn't match for a particular property, perhaps it shouldn't have been made an instance or subclass, or perhaps that property shouldn't have been on the class. Ghouston (talk) 23:40, 19 April 2018 (UTC)
But what you are actually saying, yeah it would be nice if you could see an item with all of the properties, including those inherited, and get a warning like a constraint violation if there were conflicting values. Ghouston (talk) 23:46, 19 April 2018 (UTC)
@Ghouston: It's not automatic. For example, all identifiers are not inherited, images are not inherited, "has part" is not inherited, "inception" is not inherited (also if children items shouldn't have an inception date previous to the parents one), and so on.--Malore (talk) 00:53, 20 April 2018 (UTC)
Hmm, yes changing properties makes sense in these cases, because the instance or subclass has more specific values that can be used. It would be nice if the superclass values were also valid, e.g., the image on human (Q5) was one that could be applicable to any human, but that won't necessarily be the case. Ghouston (talk) 01:02, 20 April 2018 (UTC)
@Ghouston:Maybe I used the wrong examples, but there are values that are inherited (all "has quality" values), values that are inherited but can be further specified ("inception", "images") and values that are not inherited (identifiers, "has part", "named after") because they refer only to that specific word or concept.--Malore (talk) 10:51, 20 April 2018 (UTC)
Formally claims in one item do not apply for anything outside of that item, thus a formal or even automatic “inheritance” is not possible—although it implicitly often makes sense to assume one. There are some exceptions: we have, for example, very few instances of transitive property (Q18647515) (see here), where some kind of transitivity over property paths of those listed properties is implied. I am not sure whether there is anything else, but at this point I wouldn’t expect much more. —MisterSynergy (talk) 11:06, 20 April 2018 (UTC)
@MisterSynergy:Is there a reason for this? Because I think this feature would allow to save a lot of time and to easier spot wrong values and properties.--Malore (talk) 15:40, 20 April 2018 (UTC)
I was not involved when this was set up and I do not really know the reasons, thus I have to speculate. There are probably way too many exceptions within any set of items that instantiate a particular class item, so that automatic inheritances would go wrong way too often. With transitive subclass relations (as they are in place right now), things would even be more complicated. The world it quite complex and diverse, and so is the representation of it that we build here …
However, with the Wikidata Query Service it should be possible to investigate and compare all kinds of data sets, also particularly for wrong values/outliers/special cases and so on. Most users have to learn SPARQL first, unfortunately. —MisterSynergy (talk) 16:17, 20 April 2018 (UTC)
So it's just the opposite to what I guessed, but it makes it easier. mw:Wikibase/DataModel mentions inheritance but doesn't seem to say anything about this. Ghouston (talk) 11:06, 21 April 2018 (UTC)

Proposed property for Instagram tagsEdit

Wikidata:Property proposal/Instagram_tag was closed as "not done", because "there were no examples provided of official sources endorsing instagram tags". Such endorsement is not a requirement for property proposals (and evidence of it was not even asked for, in the discussion). Furthermore, there were more supports than objections, with the three objections being stated on the basis of the data-type, rather than objections to a property in principle. None of the supporters objected to the proposed datatype.

For those reasons, I have asked the closer, User:Micru, three times to reopen it, but they have refused, expressing his own partisan view on the datatype. The proposal should be reopened forthwith, so that it can be reviewed by someone else, with a neutral approach and without bogus criteria. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:22, 10 April 2018 (UTC)

I will agree with you that this was closed prematurely—not saying that it should be created at this point, though. I will reopen this within the next two hours, @Pigsonthewing:, once I get to a computer. Mahir256 (talk) 14:41, 10 April 2018 (UTC)
@Mahir256: Nudge. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:58, 19 April 2018 (UTC)
@Pigsonthewing: As you have said below, this discussion has not been resolved. I am thus respecting Micru’s request that a clear outcome be achieved here first before reopening the proposal. (To be clear, if no admin had asked me to hold off on it within the two-hour window, I would gladly have reopened it then.) Mahir256 (talk) 19:51, 19 April 2018 (UTC)
Not sure. It is an old proposal.
--- Jura 14:43, 10 April 2018 (UTC)
@Mahir256: Wait to reopen the proposal until this conversation reaches a clear outcome. Micru (talk) 14:58, 10 April 2018 (UTC)
  •   Question given the various comments of the participants, what outcome would you consider appropriate?
    --- Jura 14:41, 10 April 2018 (UTC)
There were legitimate concerns raised about this property proposal, mainly that Instagram tags are not curated, not sourced, and not endorsed by anyone, and as a result I believe this should not be used as an external identifier. I suggested Andy to start a new proposal with data type "string", same as property Twitter hashtag (P2572).
The discussion was stalled since January, and while the number of support/opposition can give an indication about the general perception of a property, it is never enough to justify by itself the creation of a property. I feel attacked by Andy questioning my integrity as property creator just because the outcome was not in his favor. Micru (talk) 14:50, 10 April 2018 (UTC)

Restored from the archives, as unresolved. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:57, 19 April 2018 (UTC)

Wonder who's to blame for that. Sjoerd de Bruin (talk) 19:13, 19 April 2018 (UTC)

Hemp fiber in English and Korean WikipediasEdit

Not sure what to do with this; 삼베 on kowiki links to nothing on enwiki when there is an article for it, sambe on enwiki. But the English article is about the specifically Korean cultural usage. So I'm not sure hemp fiber (Q13414920) with links to other languages should be broken (e.g. de:Hanffaser). Help! Bri (talk) 19:26, 19 April 2018 (UTC)

English Wikipedia does not have an article on (generic) hemp fiber (Q13414920), so there is no link there to 삼베. Hemp fiber is discussed in Hemp which is linked to hemp (Q7150699) (edited: and in Fiber crop). Many languages have both articles (and it looks at a quick glance like some of them are not linked to the best WD item ... Catalan Fibra de cànem pretty clearly is about the fiber, not the industrial uses of the plant). As you point out, Enwiki sambe is specifically about cultural Korean usage, and I think its WD item Sambe (Q48724197) should probably be a subclass of hemp fiber (Q13414920). If the RFC to allow links to redirects is approved, the ENwiki redirect Hemp fiber would be pointed to hemp fiber (Q13414920) which would solve this problem.
If KOwiki allows manual interwiki links, you could link KO 삼베 to EN Hemp or sambe as you please. But as things stand, I don't know of a way to make this link via Wikidata. (Other than the manual hack that is sometimes used to link redirects to WD items).- PKM (talk) 19:53, 19 April 2018 (UTC)
Someone could also write a new, separate article on Hemp fiber for ENwiki - the current redirect goes to Fiber crop. - PKM (talk) 19:59, 19 April 2018 (UTC)
And it turns out we had two WD items for hemp fiber. I have merged them now. - PKM (talk) 20:33, 19 April 2018 (UTC)
Thanks everyone. I'll probably go ahead and write Hemp fiber for enwp soon. Bri (talk) 02:41, 20 April 2018 (UTC)

Payment cards vs systemsEdit

Is there any valid way that payment card (Q1436963) can be linked to payment system (Q986008)? It's not a subclass, because a payment card isn't a type of payment system, just a thing used by such a system. I don't think part of (P361) or used by (P1535) can be used either, since the inverse statements don't apply (there are payment systems that don't use cards, like cash and barter). Ghouston (talk) 00:18, 20 April 2018 (UTC)

@Ghouston: A possible way: payment card (Q1436963)=> manifestation of (P1557) => payment system (Q986008).--Micru (talk) 18:20, 20 April 2018 (UTC)
I think it has the same problem as subclass, since a payment card isn't a payment system, just a part of one. facet of (P1269) doesn't have the inverse constraint like part of (P361), but would also imply to me that every payment system would have it. Ghouston (talk) 23:05, 20 April 2018 (UTC)

part of (P361) seems problematic in general, like on automobile (Q1420) which lists various parts, some of which an automobile doesn't actually need to have. E.g., an electric automobile doesn't have a fuel tank (Q1411232). Ghouston (talk) 23:18, 20 April 2018 (UTC)

I think that one can be fixed with automobile (Q1420) has parts of the class (P2670) automotive part (Q46765731). Ghouston (talk) 00:06, 21 April 2018 (UTC)
Except then things like wheel (Q446) aren't automotive part (Q46765731) as such...this is too hard. Ghouston (talk) 00:10, 21 April 2018 (UTC)
  • "input device" would probably be wrong on several levels.
    --- Jura 06:32, 21 April 2018 (UTC)
  • It's interesting that part of (P361) has an inverse constraint, but its inverse has part (P527) doesn't. That's handy for generic parts that can be parts of various items, like wheels. But payment card (Q1436963) shows that the opposite can also occur: maybe the constraint should just be dropped. Ghouston (talk) 12:13, 21 April 2018 (UTC)

Display of a thumbnail for image propertiesEdit

Hello all,

Since yesterday, the statements including a Commons media file are now displaying a thumbnail of the picture in Wikidata. Clicking on the name of the file opens Mediaviewer. (try it on your favorite item)

Note that you may need to purge the page to see this change appears.

It's possible that you encounter a bug, in that case, feel free to let a comment and a screenshot on that ticket.

Thanks, Lea Lacroix (WMDE) (talk) 05:27, 20 April 2018 (UTC)

@Lea Lacroix (WMDE): both logged in and logged out I don't see any change. I don't see a thumbnail and I don't get a link to the MediaViewer. Is the change live at the moment? Can you provide a screenshot here how it is supposed to look? Multichill (talk) 09:36, 20 April 2018 (UTC)
Hello Multichill and all,
Because of a problem during the deployment train, the feature is currently removed. Sorry for the inconvenience, I'll let you know as soon as it is back :) Lea Lacroix (WMDE) (talk) 10:44, 20 April 2018 (UTC)

Quick community survey: notability of family members due to “structural need”Edit

There are occasionally items about family members of notable persons (parents, children, siblings, and so on) listed at Wikidata:Requests for deletions (there are some cases listed these days). When they are linked from the item of the notable person, it is often argued that these family members are also notable due to “structural need”. However, I am not sure whether such relations really create “structural need”. One could easily extend this approach and consider the relatives of the family members also as notable, and very soon each and every human being would be “notable” for Wikidata. We simply don’t have the capacities to manage this appropriately; I have also serious concerns about privacy issues, particularly (but not only) if items about minors are created.

The ongoing Wikidata:Requests for comment/Privacy and Living People as well as Wikidata:Living persons (draft) and Wikidata:Living people do not cover this problem appropriately, to my opinion. What does the community think about the problem? In which situations does the “structural need” criterion justify to have family member items? In which cases not? What’s the use case to equip family members with individual items when their only (notability-relevant) achievement is to be the relevant of someone else? Which minimum sourcing requirements should we have for those cases? What else do you have to add to this survey? I am open for any kind of input here, thus feel free to express your opinion. Thanks, MisterSynergy (talk) 10:56, 20 April 2018 (UTC)

The RFC and living persons policy proposal are not concerned with notability, that's a separate issue. I think if the family members would be indicated in any way on a language wikipedia article about the "notable" person, then we should have (limited) items for them in wikidata. Of course the information on them should come from reliable sources, as covered in the RFC etc. ArthurPSmith (talk) 12:22, 20 April 2018 (UTC)
Part of the problem is that we do not define "structural need". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:52, 20 April 2018 (UTC)
The structural need for family members is particularly to establish and show relations.. So fathers, mothers link their children to grand parents.. Genealogy is one structural need. Another is for people who won an award or who held a position. The need is in making such lists complete. Thanks, GerardM (talk) 13:54, 20 April 2018 (UTC)
The structural need is that if you want to name somebody's spouse or child you need to create an item for them. The questions are whether their spouse and child really need to be named, and if so, how many additional statements can be added to these spouse/child items. Potentially such additional statements could require the creation of further items for the same structural need, and so on until everybody is on Wikidata. Ghouston (talk) 02:44, 21 April 2018 (UTC)
  • I'm curious what relations would need to be established and shown to minor living children.
    --- Jura 06:29, 21 April 2018 (UTC)
  • There are a lot of historical dynasties in art, politics, local land ownership etc that it is useful to be able to retrieve precisely. If we have an item for the grandparent and an item for the grandchild, then I think in most cases it would be useful to have an item for the parent in between. In very many cases the relevant people will probably not be living; but even when they are living, the connection is very likely to be public and generally known, through standard reference sources such as (in the UK) Who's Who, Burke's Peerage, Debrett's Distinguished People of Today, newspaper profiles, etc. When we have such a source for the information, that is readily publicly accessible, then I think the item would be appropriate to create. For more distant relationships relative (P1038) with type of kinship (P1039) is available. Jheald (talk) 14:33, 20 April 2018 (UTC)
The links also make possible amusing queries such as current members of the House of Commons descended from possibly mythical ancestors. Jheald (talk) 14:45, 20 April 2018 (UTC)
  • For deceased persons, I think it is helpful to create items for those between people and their grandparents.
    --- Jura 06:29, 21 April 2018 (UTC)
  • Keep it limited to notable persons. If parents is not notable then relative (P1038) should be used for grandparents and other relationships with qualificator type of kinship (P1039). Breg Pmt (talk) 09:01, 21 April 2018 (UTC)
    • Given that our notability criteria include "structural need", which is undefined, that doesn't really advance us any further. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:34, 21 April 2018 (UTC)
  • I appreciate the concerns where the newly-created items are themselves living people, and a decision on that might be useful, but I would strongly urge that we don't make a blanket policy against creating these linking items for non-living people. This sort of thing is massively useful for building relationship links between historical figures, as Jura & Jheald say, and IME the relative (P1038) approach for "skipping" people doesn't work well compared to a standard family relationship.
    One approach might be to firm up "structural need" to say that ideally you need the item to be linked from *two* independently notable items, or at least be part of a chain that connects two items. So we would allow, for example, linking someone to their great-grandmother by creating the father and grandmother items, but discourage creating items for all the cousins etc who aren't part of the direct chain. Andrew Gray (talk) 09:38, 21 April 2018 (UTC)

Colors and pigmentsEdit

Just confirming - are we agreed that we need separate items for colors and pigments? (See rose madder (Q2609895) where the linked articles seem to be a mix of info about the pigment, the color, or both). It seems to me they should be separate, linked by color (P462). - PKM (talk) 21:25, 20 April 2018 (UTC)

+1 for separated items. And pigment should be named using the name of the substance/chemical compound. Snipre (talk) 22:16, 20 April 2018 (UTC)
Thanks for the +1. Are you saying your preferred label for Prussian blue (Q421894) would be 'Ferric ferrocyanide'? I would disagree with that. I prefer that standard artists' pigment names as used in Getty AAT, with the chemical compound names as aliases. But then that's the domain I am used to working with.- PKM (talk) 22:50, 20 April 2018 (UTC)

Merge person Friedrich BienemannEdit

Friedrich Bienemann (Q12362741) = no label (Q19197249) 77.179.147.176 15:29, 21 April 2018 (UTC)

  Done Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:55, 21 April 2018 (UTC)


I think that this discussion is resolved and can be archived. If you disagree, don't hesitate to replace this template with your comment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:55, 21 April 2018 (UTC)