Wikidata:Project chat: Difference between revisions

Content deleted Content added

Inline

Revision as of 15:32, 3 April 2019

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
Wikidata Telegram group

Start a new discussion

Edit

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 2024/12.

Popular classifieds website Friday-Ad

I'm looking to add the Friday-Ad to wikidata. It's a very large UK classifieds and commununity website, popular down in the south of England. It's a leading marketplace for motors, pets and all sorts of second hand goods. You can view it here: https://www.friday-ad.co.uk/

Its similar to Gumtree (https://www.wikidata.org/wiki/Q5618258) and Preloved https://www.wikidata.org/wiki/Q17014403 – The preceding unsigned comment was added by Miloatfriday (talk • contribs) at 2019-03-12 14:13 (UTC).

Scientific names of taxa should be a separate entities from the taxa themselves

Currently, a scientific Latin name for an organism is a property of a taxon, rather than an entity in of itself. However, this causes inconsistencies. Each Latin name has one or more authors, an associated protolog, a publication and a type specimen in a collection. These pieces of information are only related to the Latin name and not the taxon. The taxon is a scientific concept and the earliest valid name is chosen as a label for this concept. This problem with the data model means that the International Plant Names Index (Q922063) identifiers are being used as properties of taxa, which they are not. They are identifiers for published Latin names (valid or not). This is causing me problems because I want to link nomenclatural type specimen details with the name that they are types of, but I can only link them to taxa.

How do we go about getting this change?

Is there a will to fix this?

How do we represent type specimens in Wikidata and their links to names?

I imagine it will be painful, but it is better to do this sooner rather than later Qgroom (talk) 09:20, 17 March 2019 (UTC)[reply]

I agree with the general problem and think it would be desireable to the taxons in the Q-namespace and the names in the L-namespace, where names belong. ChristianKl ❪✉❫ 20:57, 17 March 2019 (UTC)[reply]

At this stage, this involve splitting hundreds of thousands of items from each others. As much as I like the idea myself, I don't think it's realistically feasible whatsoever (not to mention how the distinction is completely lost of most people who are not deeply familiar with codes of nomenclature for organisms). Circeus (talk) 11:29, 17 March 2019 (UTC)[reply]

It might be hard, but if the data model is demonstratably wrong isn't the situation only going to get worse the longer it is left? It may be hundreds of thousands of items now, but it will be millions of items eventually. The problem will mean that Wikidata will fail to be useful for biodiversity informatics, where it could be a real game changer. Wikidata's unique selling point it that it can be fixed. Qgroom (talk) 12:15, 17 March 2019 (UTC)[reply]

@Qgroom: Some thoughts from 2016. --Succu (talk) 13:06, 17 March 2019 (UTC)[reply]

My outside impression is that we had someone complain the other day about Wikidata doing the opposite? --- Jura 11:51, 17 March 2019 (UTC)[reply]

The opposite of what? Qgroom (talk) 12:16, 17 March 2019 (UTC)[reply]

The opposite of what you are complaining about by creating new items for every name. --- Jura 12:20, 17 March 2019 (UTC)[reply]

I suppose Wikidata could get so big that it just grinds to a halt, but there are an estimated 9 million species. Not all of these are described, but even if they were and each one had two names then it is not going to be a number that Wikidata can't handle. Apparently, there are 2.5 million scientific publications published every year and these are getting added to Wikidata Qgroom (talk) 12:33, 17 March 2019 (UTC)[reply]

I think it's already being done. If homo sapiens is or was also called something else, there would be a separate item for that name. We just generally don't have an item like Q5. --- Jura 12:45, 17 March 2019 (UTC)[reply]

Although Q5 has the description "common name of Homo sapiens..." it is clear from its properties that it is refering to much more than the name. I suspect Q5 and Q15978631 should be merged, because they both describe the concept of humanness and neither describes the name, whether Latin or English. – The preceding unsigned comment was added by Qgroom (talk • contribs) at 12:58, 17 March 2019‎ (UTC).[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

This is certainly a serious concern, which is stopping the use of Wikidata in other WMF projects, and externally. It's also internally incongruent - we don't define table (Q14748) as "name of a piece of furniture". One of the many prior discussions is "What heart rate does your name have?". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:59, 17 March 2019 (UTC)[reply]

Thanks @Succu: and @Pigsonthewing: for those links to earlier discussions on the topic. I had imagined the subject was going to be difficult, I was not wrong. – The preceding unsigned comment was added by Qgroom (talk • contribs) at 14:12, 17 March 2019‎ (UTC).[reply]

@Pigsonthewing: No, please don't merge human (Q5) and Homo sapiens (Q15978631), they reflect closely related, but distinct concepts. When we started out with reflecting human genes on Wikidata, we used the statement found in taxon (P703) human (Q5), however, this lead to inconsistencies, basically because of human (Q5) not being a taxon (Q16521) and as such didn't fit with genetic models. You could argue that by simply making human (Q5) instance of (P31) taxon (Q16521) fixes this, however there are examples (e.g. Lexa (Q23023325) where an item is righteously instance of (P31) human (Q5), but not instance of (P31) Homo sapiens (Q15978631). --Andrawaag (talk) 10:13, 18 March 2019 (UTC)[reply]

Don't worry I've no intention of messing with humans. The point is, humans are exceptional in a number of ways and in this case we should not get deflected by these special cases.Qgroom (talk) 11:49, 18 March 2019 (UTC)[reply]

@Andrawaag: Where did I propose such a merge? I've fixed Q23023325, which should not have been using Q5. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:09, 18 March 2019 (UTC)[reply]

@Pigsonthewing: You were the first signature after "I suspect Q5 and Q15978631 should be merged". It seems that I was wrong there, appologies. --Andrawaag (talk) 22:23, 18 March 2019 (UTC)[reply]

I'm hardly a WikiData expert, but about all i do on here relates to taxa. Here are some thoughts:

Many common names relate to more than one taxon, so if this separation happens, it needs to accommodate many q-items using the same common name item.
Many taxa already have more than one scientific name, mainly in the form of synonyms. I am under the impression that each synonym should have it's own separate q-code. Even if this is not the desired policy, it is certainly happening in many cases. In these cases, it approaches the situation requested above. I think if we want one item for a common name and scientific name, we'd have to combine more than one scientific name. Personally, with how names change back and forth this may be unwise.--NessieVL (talk) 01:41, 19 March 2019 (UTC)[reply]

Here are some thoughts...

Use cases

Finding where type specimens are
Testing that there is only one holotype, lectotype or neotype.
Testing other rules of nomenclature
Testing that the authorship of names is correct
Finding the literature on the naming of taxa
Linking names of taxa to authors
Testing that the name has been legitimately typified
Identifying syntype material

Ways forward?

Ignore the cases of cats, dogs and humans and start with the more obscure and therefore less controversial taxa.
Continue labelling taxon concepts as they are now as Instance of P31 Taxon Q16521 with a label, such as "Viola lutea"
Add new scientific name items as Instance of P31 name Q82799 (or preferably a new item class - scientific Latin name)
Label these new scientific name items with something like "Viola lutea Huds. (name)"

Doubtless I'm being too naive, but if there are ways to breakdown a difficult problem into manageable chunks then perhaps it is solvable. – The preceding unsigned comment was added by Qgroom (talk • contribs) at 14:12, 17 March 2019‎ (UTC).[reply]

PS: One thing I note is that previous discussions have conflated taxonomy and nomenclature. The later is concreate, has tightly defined rules and is therefore much more tractable in a database than taxonomy, that often comes down to a matter of opinion. – The preceding unsigned comment was added by Qgroom (talk • contribs).

I think we should get inspired from Darwin Core, with their occurence system that allow to store, and then retrieve, the infos about specific specimens into databases. If we allow that a specific specimen, or group of specimens, can have an item, then it will be easy to store a lot of infos including something like subject has role (P2868) holotype (Q1061403) of (P642) of the taxon of your choice.
Furthermore in the perspective of the future that binds more and more Wikimedia Commons and Wikidata, it will be great if one day we can import with automated tools the images of free datasets into Wikimedia Commons and the and related information into Wikidata, example see this occurence and this image manually uploaded into Commons and where related information is currently poorly rendered and used (+the work is too important to be done manually in the long run). I dream that one day the free datasets of gbif be imported into the Wikimedia Project (medias in Commons and infos in Wikidata). Christian Ferrer (talk) 21:30, 17 March 2019 (UTC)[reply]

Yes, but one specimen can be the nomenclatural type of multiple names and be cited in several publications. So it doesn't get around that the name is an entity in of itself. All the nodes of the biodiversity knowledge graph are individual entities (http://bionames.org/~rpage/towards-knowledge-graph/).

If you have an issue with the current system, then with the name as an entity, you move this issue to this new entity, but you solve nothing. Christian Ferrer (talk) 12:15, 18 March 2019 (UTC)[reply]

Example, here Dermechinus horridus (Q2743032) and the synonym (also the original combination) Echinus horridus (Q62085775). If you have two different name, and that you need the both names here for a strucutred data purpose, then create a new item, as I show in my example. Or as much as you need. Christian Ferrer (talk) 12:25, 18 March 2019 (UTC)[reply]

Two properties pointing to the name

I am wondering if the convention used in Wikicite wrt to author names in using both author (P50) and author name string (P2093) can apply here as well. The ideal solution would be to change taxon name (P225) to accept items instead of string, but given that taxon name (P225) is already in widespread use changing seems impossible. Hence mimicing the wikicite solution with authors helps? Just my 2cts. --Andrawaag (talk) 22:06, 17 March 2019 (UTC)[reply]

Yes, I think that taking inspiration from the item/ string split between author (P50) and author name string (P2093) looks promising. In that vein, I think the current taxon name (P225) should remain as a string property, and the only thing we would have to change there would be the labels of P225, to "taxon name string" (and equivalents in other languages). This would then be complemented by a new property "taxon name" (or perhaps better "taxon name item", to reduce the ensuing confusion) that would point to an item. Once we have a P50 statement on a publication item, we usually remove the P2093 one (storing its value via object named as (P1932)). I think the "taxon name string" statement would eventually have to be deleted from the taxon item (and migrated to the taxon name item), but perhaps we should allow for some more time here than for the P50-to-P2093 conversion. --Daniel Mietchen (talk) 03:23, 18 March 2019 (UTC)[reply]

No. That will not work. Properly done, a taxon has four parts; the name (ie taxon), the author (ie possibly multiple names), the publication and the date. This is what it takes to uniquely describe a taxon. I have said it before and I say it again. Thanks, GerardM (talk) 06:23, 18 March 2019 (UTC)[reply]

I am not sure I understand. Isn't the issue here that there is a need to distinguish between a taxon and a taxon name. You argue that a taxon is described by 4 concepts of which its name is one. But you also argue that the name is the taxon, which at the same time is one of the four characteristics of a taxon. Isn't this the kind of Droste effect being addressed here? --Andrawaag (talk) 09:36, 18 March 2019 (UTC)[reply]

I think the anology with author (P50) and author name string (P2093) is a good solution that is non-disruptive, but allows progress. How do we get this done? Qgroom (talk) 11:57, 18 March 2019 (UTC)[reply]

There is no need to separate the taxon from the taxon name, an item about a taxon is and should stay an association of different things (name, author, date). In case of synonymy, then this is not anymore the same association and a new item is needed and have to be "instance of/ synonym of..". In the extend, of course, that we think relevant to have this item here, example in case of original combination, but we don't need to list all synonyms IMO, though the debate can stay open. But in all case when a species is "renamed" and that the a new name is accepted, we must absolutely create a new item, not change what is written in the string field "taxon name", as it is sometimes the case here. To come back about a potential separation of the taxon name, this will solve nothing of any potential issue (if any), it will just complicate things. A taxon is absolutly not "a thing with potential different names", because when the names are different then we talk about different taxa. A taxon without "taxon name" is not a taxon. We are not going to reinvent science. Christian Ferrer (talk) 12:12, 18 March 2019 (UTC)[reply]

@Christian Ferrer: "A taxon without 'taxon name' is not a taxon" – the ICZN in the glossary entry for "taxon" says it's a taxonomic unit whether named or not, so you are using a different definition to the Code. Peter coxhead (talk) 17:27, 19 March 2019 (UTC)[reply]

@Peter coxhead: There is no need to push the ontology so far. As a data, yes of course yes, a taxon is not a taxon without a name and without the resulting properties of that taxon name. Christian Ferrer (talk) 17:59, 19 March 2019 (UTC)[reply]

There is a need. As said before, a taxonomic name is linked to a type specimen, an author and a protologue and these are not properties of the taxon, they are properties of the name. The taxon, is a biological hypothesis and is much more fluid in its scope. There is no single authority for which name is accepted. What is accepted is always a matter of opinion. On the other hand taxonomic names are concreate, founded on clear rules. Taxonomic synonyms are not just different names for the same thing. A name can even exist even if we don't know what taxon it is supposed to represent. These names are an important link between the biology, collections and scientific literature. Qgroom (talk) 14:21, 18 March 2019 (UTC)[reply]

Each taxa item here has currently only one taxon name, almost all if not all the other properties (included, and in addition of what you quote yourself, the parent taxon, and all external identifiers) are relative to that specific name, you said it very well, and if you move the name then you need to move all the rest, therefore you move nothing. The only thing that can stay, and not for all cases, is the common name. Christian Ferrer (talk) 17:46, 18 March 2019 (UTC)[reply]

@Christian Ferrer: each item incorrectly claimed to be an instance of a taxon has only one taxon name, because it is actually an instance of a taxon name, not a taxon. See #Previous discussion below. Many taxa are represented here by multiple taxon names. Peter coxhead (talk) 17:02, 19 March 2019 (UTC)[reply]

@Peter coxhead: Yes and no. What would be an instance of taxon otherwise? what will be the label? it is just a concept that take consistency only when it is named and defined. And as I noted above, absolutly all the other properties currently used are depending of that name and definintion, therefore if you have an item for the taxon name, you have in this item all the other properties too (external identifiers, rank, parent taxon, publications, author, sitelinks, ect...). What will be in this item "taxon" in addition of a property taxon name where the value will be the Qitem of the taxon name? absolutly nothing because everything flows from this taxon name and from all the properties that are unique to that taxon name. The only thing that it will allow to do it is the possibility to add multiple values to that property taxon name, but ultimately it does not bring nothing because currently you can create synonym items as much as you need. Therefore to change completely will create a lot of issues to solve none. Christian Ferrer (talk) 17:50, 19 March 2019 (UTC)[reply]

Assuming that we were changing "instance of taxon" to "instance of taxon name", not a single property of Holothuria scabra (Q2395506) will be changed. And what? The only result will be a potential (big) disrupion of the Wikimedia projects that are currently using tools that works with "instance of taxon", but what's new? What is the interest to materialize the "true" concept of "taxon" in a structured data? what will be the name of that item "taxon", what label? the accepted name, maybe? but this is the current situation, ....no?!? the other names are synonyms, thing that they can currently be, so what new? Christian Ferrer (talk) 19:00, 19 March 2019 (UTC)[reply]

In my opinion Wikicite is a disaster creating wrong titles, duplicated items etc. example often making it hard to add has basionym (P566) or original combination (P1403) based on sources. --Succu (talk) 21:28, 18 March 2019 (UTC)[reply]

Possible solution

With our existing infrastructure we can use lexemes for the latin names and use item for this sense (P5137) to link them to our taxon items, the new lexeme/sense items can get the information about taxon author and publication. A bot could simply do this for all the existing taxons that we have. As a next step we can merge items that describe the same taxon via the existing information from taxon synonym (P1420). Does anybody see problems with doing that? ChristianKl ❪✉❫ 12:09, 18 March 2019 (UTC)[reply]

As far as I'm concerned, if Dermechinus horridus (Q2743032) and Echinus horridus (Q62085775) can be merged without we lose any informations, including until the BHL link, then why not. Christian Ferrer (talk) 12:42, 18 March 2019 (UTC)[reply]

Though this solution is at the opposite of the original subject, that tend to divide than to merge. For a structured purpose, e.g. if we need to link a specimen as to be a specific type, example "holotype", of a specific taxon with a specific name (even if is not the current accepted name) then we need an item for this specific taxon. And this is currently possible with the current system, see my example. You can very well have a specimen that is the holotype of Echinus horridus (Q62085775), while the accepted taxon is Dermechinus horridus (Q2743032). For that purpose of what is needed is that we allow to create items for specific zoological specimen (Q2114846) or something similar. No really, no, in taxonomy, the same thing with two different name is not the same thing but well two different things, we need to keep the item separate. Christian Ferrer (talk) 12:55, 18 March 2019 (UTC)[reply]

Yes, I agree Dermechinus horridus (Q2743032) and Echinus horridus (Q62085775) should be merged, because they refer to exactly the same species concept. However, these items have conflated name information and taxon information. So that the properties taxon author citation (P6507) and P5326 (P5326) would then need cleaning up. If names were separated from the species concept then multiple species concepts could coexist, as they already do in the real world. Qgroom (talk) 14:35, 18 March 2019 (UTC)[reply]

I fail to understand why we should clean up the original publication of the original name, this is useful information. As well as the author citations of both items are useful, as these both citations are (different) currently used, example. Further more a taxon name is linked to one specific author citation, therefore if you quote the name somewhere you have to quote the author citation too. Christian Ferrer (talk) 18:13, 18 March 2019 (UTC)[reply]

@Christian Ferrer:Why do you consider that to be important. Why isn't it enough when we store the orginal name in the source document with some form of 'states as'? ChristianKl ❪✉❫ 15:48, 18 March 2019 (UTC)[reply]

@ChristianKl: Here the taxa items currently need a rank, a name and a parent. A taxon synonym have obvioulsy a different name, may have a different rank (e.g. a species can be a synonym of a subspecies), and may have a parent taxon different (in the facts all is (or may be) different, as pointed there). I fail to understand what is the interest to merge such things, in addition of that I fail to understand how can work well a taxon chain like that. Though this is not because I don't understand it that it is impossible. Christian Ferrer (talk) 17:58, 18 March 2019 (UTC)[reply]

I've listed a few of the use-cases above. These can't be resolved by treating taxonomic names and taxa as the same thing, nor by treating names as mere labels. The inconsistencies are already apparent in the Dermechinus horridus (Q2743032) and Echinus horridus (Q62085775) example. Qgroom (talk) 17:40, 18 March 2019 (UTC)[reply]

What kind of "inconsistencies"? could you please more specific? --Succu (talk) 21:31, 29 March 2019 (UTC)[reply]

@ChristianKl: I'm a Wikidata beginner. Could you point me to some material to explain your lexeme proposal? Qgroom (talk) 14:40, 18 March 2019 (UTC)[reply]

Lexeme's are entities that represent how a given concept is called in a given language. The were recently introduced to map to Wikidictionary entities. https://www.wikidata.org/wiki/Wikidata:Lexicographical_data/Documentation provides more information. ChristianKl ❪✉❫ 15:48, 18 March 2019 (UTC)[reply]

I doubt binomen (Q864016) should be treated as lexemes. --Succu (talk) 20:46, 18 March 2019 (UTC)[reply]

Claiming that Dermechinus horridus (Q2743032) and Echinus horridus (Q62085775) refer to "the same species concept" is a huge stretch. In almost all cases it is impossible to say to what species concept a name refers to without citing at least one actual taxonomic paper. There are very few Wikidata items that refer to a particular species concept; this is only possible if the taxon is very well-known and uncontroversial or if an item is defined in terms of a particular taxonomic position.

The basic issue is that scientific names can be databased very easily, and one name per item allows adding all nomenclatural information, such as authorship of the name, and any detail on typification (in principle, we may need extra properties).

On the other hand taxa can not be databased at all (with a few exceptions) except by using scientific names. And scientific names can refer to any number of differently defined taxa.

Having one item for one scientific name allows any bit of data from the literature to be databased accurately. Recording information accurately surely should be the foundation of any database policy. - Brya (talk) 17:51, 19 March 2019 (UTC)[reply]

"refer to "the same species concept" is a huge stretch." yes, and this is why there is currently two different items. Christian Ferrer (talk) 18:03, 19 March 2019 (UTC)[reply]

Types

We have taxonomic type (P427) to add them. What we are missing is a data model for types at species rank and below. This are your major use cases above, Qgroom. How should we do this? --Succu (talk) 19:09, 18 March 2019 (UTC)[reply]

taxonomic type (P427) is about type species, despite the similar sounding name, this is something completely different to a type specimen. Qgroom (talk) 20:17, 18 March 2019 (UTC)[reply]

No. Please see Rausch 572 (Q19359611). --Succu (talk) 20:30, 18 March 2019 (UTC)[reply]

I don't understand. Rausch 572 (Q19359611) is a type specimen, it is not a necessarily a taxonomic type (P427) as it is defined (BTW that's a terrible label). Qgroom (talk) 21:27, 18 March 2019 (UTC)[reply]

Hopefully [1] Acanthocalycium thionanthum (Q337710) and Acanthocalycium ferrarii (Q337692) are not based on the same type. If the would be the case replaced synonym (for nom. nov.) (P694) should be applied. --Succu (talk) 21:42, 18 March 2019 (UTC)[reply]

The replaced synonym (for nom. nov.) (P694) is being used incorrectly in the item Acanthocalycium thionanthum (Q337710). The definition of replaced synonym (for nom. nov.) (P694) is "the type genus of this family (or subfamily, etc), or the type species of this genus (or subgenus, etc)". It is therefore referring to a taxon, not a specimen. So it can't be Rausch 572. This is the sort of logical inconsistency I want to resolve by making a clear distinction between taxa and taxonomic names. --Qgroom (talk) 05:51, 19 March 2019 (UTC)[reply]

I assume what is intended is taxonomic type (P427) in Acanthocalycium ferrarii (Q337692). This P427 when proposed was indeed intended for taxa, but it is not inconceivable to expand its use to include type specimens / illustrations / descriptions. However, that would mean creating an item for every type, which seems like an enormous, even a practically impossible (?) amount of work. So maybe we do need new properties. And yes, "taxonomic type" is a terrible label, but pragmatically it does need "taxon" or "taxonomic" in the name, in order not to be lost here, in this database with a huge span of coverage. - Brya (talk) 05:09, 20 March 2019 (UTC)[reply]

Sitelinks

Where to put them? Do Wikimedia project describe taxon concepts or only list names according to a special source? This includes the automatic creation of items here based on an external id. --Succu (talk) 19:38, 18 March 2019 (UTC)[reply]

Note that I don't know exactly how that works but in case of synonym in Wikimedia Commons the links may be given, example. Christian Ferrer (talk) 19:58, 18 March 2019 (UTC)[reply]

Commons prefers this taxonomic viewpoint. This includes the renaming of pictures to their preferred view point. I very bad practice. --Succu (talk) 20:17, 18 March 2019 (UTC)[reply]

Wikimedia uses taxon concepts, anything else would be odd. The case of Index Fungorum you mention is interesting. Index Fungorum is a list of names, like IPNI, however it links to Species Fungorum where a list of accepted taxa is maintained. A clear case of maintaining separation between nomenclature and taxonomy. Qgroom (talk) 20:26, 18 March 2019 (UTC)[reply]

Hard to believe Wikimedia uses taxon concept (Q38202667). Hard to believe all Wikimedia projects follow the same concept (birds, mammals, …) unisono. --Succu (talk) 20:38, 18 March 2019 (UTC)[reply]

Of what I point is not Wikimedia Commons practice but the fact that the sitelinks ca be retrieved from Rhodocybe nitellina (Q10434744) to Rhodophana nitellina (Q51954845), I guess with taxon synonym (P1420), the illustration can be seen in the Commons category that I have pointed. In summary the current system is good : no matter that a specific project use one name and another project use another name, because the current system allow the navigation in despite of that. And it is unrelative to the category redirect that you have pointed, there was a discussion about this feature on Commons, but I'm not able to find it, I know that taxon synonym (P1420) and our local infobox are involved. Christian Ferrer (talk) 21:11, 18 March 2019 (UTC)[reply]

The statement in Wikimedia Commons example is wrong. Index Fungorum make no judgement about whether Rhodocybe nitellina is an accepted name or a synonym. Index Fungorum is just a list of names. However, it does state that Rhodophana nitellina (Fr.) Papetti is the accepted name in Species Fungorum. Qgroom (talk) 21:26, 18 March 2019 (UTC)[reply]

Yes it does, though the link on Commons leads indeed to another page. But this is out of topic here, as we talk about sitelinks. Christian Ferrer (talk) 21:40, 18 March 2019 (UTC)[reply]

External IDs

Some of them are more dedicated to a nomenclatural act (eg. IPNI, IF, Mycobank, Zoobank should). A lot of them (NCBI, FishBase, IUCN …) follow a certain taxonomic viewpoint. That means the same ID can point to different scientific names. Others (e.g. WoRMS) are in between, they have Ids for accepted/valid names and earlier ones. Same question: where to put them? --Succu (talk) 20:06, 18 March 2019 (UTC)[reply]

Well that's why I'm asking for name items separate from taxon items, but perhaps the question was not directed at me. Qgroom (talk) 20:36, 18 March 2019 (UTC)[reply]

Where to put them at your proposed name centered items? --Succu (talk) 22:15, 18 March 2019 (UTC)[reply]

@Qgroom: Any proposal? --Succu (talk) 21:25, 29 March 2019 (UTC)[reply]

Previous discussion

The issue of representing taxon names versus taxa has already been discussed in great detail, more than once. See e.g. Property talk:P1420#data model.

The main points to be clear about first are:

A taxon is not the same as a taxon name. Explaining clearly is complicated by the different terminologies employed in the nomenclature codes, but using the ICZN here, a taxon or taxonomic unit, whether named or not, is "a population, or group of populations of organisms which are usually inferred to be phylogenetically related and which have characters in common which differentiate .. the unit .. from other such units."
A taxon can properly (validly, legitimately) have more than one name, if it is given a different placement within another taxon, and/or a change of rank. Thus precisely the same group of organisms may be given the name Muehlenbeckia florulenta (Q1101419) or the name Duma florulenta (Q18081078) depending on which genus a taxonomist considers them to belong to. Precisely the same group of organisms may be given the name Hyacinthaceae (Q13833438) or Scilloideae (Q133292) depending on whether the differences between them and other groups are considered sufficient to treat them as a separate family or to merge them into another family as a subfamily. There is no absolute right or wrong name in most such cases; it's a matter of legitimate taxonomic opinion.
In my examples, Muehlenbeckia florulenta (Q1101419), Duma florulenta (Q18081078), Hyacinthaceae (Q13833438) and Scilloideae (Q133292) are claimed to be instances of Q16521, currently labelled "taxon". They are not instances of taxon. They are instances of "taxon names". There are only two instances of "taxon" here: Muehlenbeckia florulenta (Q1101419) and Duma florulenta (Q18081078) are two names for one instance of a taxon; Hyacinthaceae (Q13833438) and Scilloideae (Q133292) are two names for another instance of a taxon.

For me, there are two issues:

Wikidata should stop claiming that instances of taxon names are instances of taxa.
Ideally, Wikidata should represent taxa as well as taxon names.

I have no idea why there seems to be resistance to (1).

(2) is, however, difficult, as is explained in detail at Property talk:P1420#data model. Here's another example. There are two ways of classifying the genus Hyacinthus used in the current botanical literature, as shown in the table below. 1–6 are the six taxa involved; the others are taxon names. (There's implicitly another taxon, with two possible names: for those who use the left hand column, Family Asparagaceae is a different taxon from #2, a taxon treated as a subfamily by those who use the right hand column).

1	Order Asparagales
2		Family Asparagaceae
3	Family Hyacinthaceae	Subfamily Scilloideae
4	Subfamily Hyacinthoideae	Tribe Hyacintheae
5	Tribe Hyacintheae	Subtribe Hyacinthinae
6	Genus Hyacinthus

So

the same taxon (defined as the same group of organisms) has more than one name – Subfamily Hyacinthoideae in the left-hand column is the same group of organisms as Tribe Hyacintheae in the right-hand column
the same name applies to different taxa – to know the composition (circumscription) of "Tribe Hyacintheae", you need to know which system is being used.

As far as I am aware, no-one has yet shown in detail with a worked example how best to represent data of this kind in Wikidata. Peter coxhead (talk) 12:26, 19 March 2019 (UTC)[reply]

This mostly very good.

However, "A taxon can properly (validly, legitimately) have more than one name," is not a fruitful way to phrase it. A taxon can properly have only one "correct"/"valid" name (some exceptions in higher ranks) from any one particular taxonomic perspective. This is the whole purpose of the nomenclature Codes. The problem (if it is that) is that there may exist any number of taxonomic perspectives, each representing a particular scientific approach. These may be regarded as several ~~mini-universes~~ alternate realities, which are mutually exclusive. In each ~~mini-universe~~ alternate reality a taxon may have a different name, but only one name at a time. For it to have a different name, there needs to be a switch to a different mini-universe.
The "instance of: taxon" is a historical oddity. Basically it means nothing more than that a P225 statement is present, and "instance of: taxon name" could also have been used. However, "instance of: taxon" is not wildly inaccurate, as such things go, since any taxon name is not only a name, but is also used to refer to a taxon (that is what it is there for). Somebody, somewhere, somewhen did use it to refer to a taxon, at least once. - Brya (talk) 18:15, 19 March 2019 (UTC)[reply]

@Brya: sure, the switch of perspective is what the two columns in the tsble above show. But changing the perspective on a taxon doesn't change the taxon, when this is defined as a group of organisms. There are properties of the taxon that are independent of the perspective. Japanese knotweed is the same invasive plant whether it's called Fallopia japonica (Q899672), Reynoutria japonica (Q18421053) or Polygonum japonicum (Q15250539). Taxa exist independently of what we choose to call them. So it seems that Wikidata should be able to model this, but it may be too difficult. Peter coxhead (talk) 23:14, 19 March 2019 (UTC)[reply]

Actually, the "perspective on a taxon" includes the definition of the taxon, called "circumscription". Sometimes, a change in perspective just means a change of rank, or assignment to a genus, but it can also mean a change in size of the taxon, sometimes quite drastically. Without citing a taxonomic reference, there is no certainty what a scientific name refers to, although often enough it can be inferred from context. - Brya (talk) 05:22, 20 March 2019 (UTC)[reply]

@Brya: a person may have had or beeen known by multiple names during their lives. But we wouldn't say that "Carl von Linné" is an instance of person and "Carolus Linnaeus" is an instance of person, yet to paraphrase what you wrote above, any person's name is not only a name, but is also used to refer to a person. It's a serious category error to confuse the name of an entity with the entity. "Carl von Linné" and "Carolus Linnaeus" are names for the same person, just as Fallopia japonica (Q899672), Reynoutria japonica (Q18421053) and Polygonum japonicum (Q15250539) are names for the same taxon. Peter coxhead (talk) 23:14, 19 March 2019 (UTC)[reply]

"Carolus Linnaeus" is listed as an instance of "human". But humans are more or less fixed single entities, legally anyway, going through several development stages. There is a lot that can be said about names for humans, too much to go into: it is not a simple topic.

Taxa are rather fluid, or more precisely "serially fixed", that is they are fixed in a particular taxonomic paper, but the next taxonomic paper may fix them differently, and so on, ad infinitum. There is also a lot that can be said about scientific names for taxa, but these are regulated in several Codes, each applying to certain groups of taxa. These provide order and certainty, as long it is recognized that one is dealing with multiple alternate realities.

The only way to have one name for each taxon would be to adopt an official WMF-Taxonomy. The objections to this are obvious: 1) it would be an Original Research endeavour, while Wikipedia's have a NOR-policy; 2) at present all Wikipedia's make their own choices for taxonomy to be used in taxoboxes, and imposing a WMF-Taxonomy on them would be unpopular; 3) any WMF-Taxonomy would go out of date quickly. - Brya (talk) 05:54, 20 March 2019 (UTC)[reply]

Adopting one name for a taxon would, I agree, be completely wrong, and I certainly have never suggested it. Wikidata must represent what all reliable data sources say, whether these sources agree or not. I made two points, which I will repeat one last time:

Wikidata should be accurate and make it clear that what are currently called instances of taxon are actually instances of taxon name. I still have no idea why this is opposed.
Ideally, there needs to be some agreed way of representing taxa (for one thing, Wikipedia articles are usually about taxa, not taxon names). However, this is a difficult problem, it turns out, and no-one has yet demonstrated a working solution. As Brya rightly says, part of the difficulty is that taxa are not as clearly defined entities as, say, people. Maybe it can't be done within the constraints of Wikidata. (Representing alternative classifications in Taxonomy templates in the English Wikipedia involves a combination of ad hoc data "fixes", like skip and variant templates, plus special programming to respond to these data fixes. And it still causes problems that are currently under discussion.) If it can't be done in Wikidata, this needs to be made very clear, so that it's understood that Wikidata cannot be used for purposes that require taxon data (e.g. taxoboxes). However, it's not quite as problematic as Brya says above. Those alternative views that concern the placement or rank of a taxon, rather than its circumscription, leave the taxon (=group of organisms) unchanged.

Peter coxhead (talk) 13:50, 20 March 2019 (UTC)[reply]

Though a taxon may have several names, when you talk about a specific taxon name then you talk about one and only one taxon. Without an author, a name, a description, ect... a taxon is just a concept absolutely indistinguishable from another taxon, it is just an idea. The "instance of taxon" here must be understood as "instance of a specific taxon as defined and described under that name". This is absolutely not untrue. Christian Ferrer (talk) 22:37, 20 March 2019 (UTC)[reply]

A general point: it is not a requirement that a taxon have a name. It is not unheard off for a taxonomist to publish a description of a recently recognized taxon without naming it. Sooner or later, after hearing the responses of collaegues, he will follow this up by naming it (or not). - Brya (talk) 18:27, 21 March 2019 (UTC)[reply]

Comment

I would like to make a couple of comments from the point of view of a nomenclatural taxonomist. However I work with the ICZN code and the other four codes of nomenclature are different in some aspects.
- A name on its own for the species level cannot be used without a genus. However names have an original combination and then can have multiple subsequent combinations. One way would be to have q items for every original combination and include on that page subsequent usages. This would then link to the q item of the current combination. This can likewise be done for synonyms. I am still only referring to species level only. For example the original combination for the mata mata is Testudo fimbriata, it was later moved and became Chelus fimbriata before its spelling was corrected (gender agreement) to Chelus fimbriatus. All this info would go on the q item for Testudo fimbriata with original refs, then link the item to the current species page for the Mata mata. As there are some 15 synonyms of the Mata mata you would need to do this for all of them. Which leads to a problem posed above which is that this is a lot of work.
- Higher orders would be simpler but also follow the same principal for synonyms. It would still be a lot of work.
- As noted above it would be easier to start this on small groups (at order level) to trial out the best way to do it before doing anything to complex groups such as vertebrates which can have 15-20 synonyms per species.
- I agree that you should list the type specimen and the type locality.
- This would be a high maintenance and highly specialised endeavour, do you really have the editors that can do this at a significant rate, and have the skills to do it. If not and be honest this is a massive undertaking and would require detailed policies for new editors to learn exactly what your doing.
- Apart from the initial undertaking this is also a significant undertaking in terms of maintenance, in reptiles over the last 20 years the number of species has gone from 6000 to 10500, with many new combinations and synonymies proposed. This is just the reptiles. The people doing this also have to maintain it, this can mean up to 10 or even more edits per year per page that would be major updates that would effect multiple pages at the same time. Of course this is actually ignoring anything outside the major divisions, so I have ignored anything prefixed by sub or suffixed by inae.
- Lastly you will need your editors of this to be very aware of the difference between nomenclature and taxonomy, to truly understand terms such as type, taxon, and many more, ie memorise the glossary of the code. You are going to have to make some decisions, there are many instances of multiple papers coming out with differences of opinion on what the correct nomenclature for a group is. How will you decide which one to use? In other words some groups are extremely dynamic and in a state of flux.
In summary although some great ideas, I think this idea is a big ask of the relatively few people who are well vrsed enough in the complex field of nomenclature to actually do it.

Scott Thomson (Faendalimas) ^talk 20:00, 19 March 2019 (UTC)[reply]

For plants there is IPNI. When it is willing to collaborate with us, a lot of the work can be shared. I personally have an 80MB database with normalised data bringing literature author references et al together for succulents. I am of an opinion that the only copyright IPNI has is the copyright on its original database, my database is based on IPNI but is a distinct database in its own right. I am willing to make it available under cc-0. Thanks, GerardM (talk) 09:42, 20 March 2019 (UTC)[reply]

Please share your database with International Plant Names Index (Q922063). Hopefully they can normalize more entries in their database. Then we can improve WD. --Succu (talk) 22:35, 27 March 2019 (UTC)[reply]

Failure of logical types

As far as I can see, you guys are arguing like words and names have a special truth. Let me see if I can give an example that explains why scientific names of taxa are not separate entities from the taxa themselves. When you imagine that you know the etymology (Q35245) of a word, how do you know that it is not a false etymology (Q17013103)? The answer is, you only have as much certainty as you can put in the linguistic comparative method (Q950464). Now, this method in linguistics is indistinguishable from those used in phylogenetics (Q171184) to elucidate taxonomy (Q8269924). What is being proposed above is to elevate folk taxonomy (Q10751930) as equal to or above scientific taxonomy. Abductive (talk) 02:51, 28 March 2019 (UTC)[reply]

[removal of a response made before this thread was moved, changing the context. - Brya (talk) 03:42, 1 April 2019 (UTC)][reply]

Yeah, I must be bewildered. Bewildered at people who think they know what other people are saying when they use words. As I say above, in the case of scientific names, the name of the taxon is the taxon. For most other things, the name of the thing is not the thing. Abductive (talk) 06:09, 28 March 2019 (UTC)[reply]

[removal of a response made before this thread was moved, changing the context. - Brya (talk) 03:42, 1 April 2019 (UTC)][reply]

Do you suppose that the word bewildered has the root "wild" in it? You are playing a game of IDONTHEARYOU, but it doesn't change the fact that the name of a species and the species are the same thing. Abductive (talk) 21:46, 28 March 2019 (UTC)[reply]

[removal of a response made before this thread was moved, changing the context. - Brya (talk) 03:42, 1 April 2019 (UTC)][reply]

As an example, I am going to quote from the en.wiki article on Quercus insignis (Q6324634). "Quercus insignis is a Mesoamerican species of oak in the white oak section, (Quercus section Quercus) within the beech family. It is native to southern Mexico and Central America, from Veracruz to Panamá. Quercus insignis is a tree. It has leaves up to 15 cm long and 8 cm across." Do you notice that the species is referred to in the singular? It is a tree. It has leaves, it is native to... We don't say "they are a bunch of trees" or "they live in Mexico". It. The species is the name, and the name is the species. Abductive (talk) 05:33, 29 March 2019 (UTC)[reply]

[removal of a response made before this thread was moved, changing the context. - Brya (talk) 03:42, 1 April 2019 (UTC)][reply]

Abductive: Could you please give some references for your POV: „it doesn't change the fact that the name of a species and the species are the same thing”. --Succu (talk) 21:06, 29 March 2019 (UTC)[reply]

Try this secondary source, https://plato.stanford.edu/entries/species, where at the beginning of section 2.2 it states that the "prevailing view of the ontological status of species" is that "species are individuals", and that "the relationship between an organism and its species is not a member/class relation but a part/whole relation". Abductive (talk) 07:57, 30 March 2019 (UTC)[reply]

Maybe you are confusing ontology (Q44325) and ontology (Q324254)? --Succu (talk) 20:37, 2 April 2019 (UTC)[reply]

Maybe I am. Abductive (talk) 08:07, 3 April 2019 (UTC)[reply]

Owl on Main Page

For some reason owl (Q8021345) is the #1 Current highlight on the Wikidata Main Page. Weirdly, this is a separate item from Strigiformes (Q25222). Some Wikipedias have an article attached to Q8021345, but most are attached to Q25222. What is going on? Abductive (talk) 05:17, 26 March 2019 (UTC)[reply]

[deletion of comment, provided when this was a straightforward question, wanting a straightforward answer. Out of place in the esoteric thread it has been moved to. These threads have as little in common as two threads possibly can that both mention taxa. The thread above deals with an philosophical question if it is possible to model (circumscriptions of) taxa other than by using scientific names (short answer: no, except in a minute minority of cases). This question deals with how animals as perceived by the general public relate to taxa. - Brya (talk) 05:28, 28 March 2019 (UTC)][reply]

This is absurd. The above "concept owl" is linked to a handful of Wikipedias; the Spanish Wikipedia, the Nahuatl Wikipedia, and the Korean Wikipedia, plus some others. There is no way these disparate people, with different native owls, are talking about the same thing. Abductive (talk) 18:31, 26 March 2019 (UTC)[reply]

And all Strigiformes are owls. I would say this is one of the few cases in which the scientific name and the common name overlap perfectly. Abductive (talk) 18:33, 26 March 2019 (UTC)[reply]

@Abductive: You're correct; but note the existence of - for example - pt:Coruja and pt:Strigiformes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:24, 26 March 2019 (UTC)[reply]

@Abductive: See the above discussion (under which I have moved your post); and the earlier discussions it links to. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:59, 26 March 2019 (UTC)[reply]

All Strigiformes are owls? No. I suspect that in Russian Tytonidae (Q27112), one family of Strigiformes (Q25222), are not called сова. --Infovarius (talk) 14:47, 29 March 2019 (UTC)[reply]

Google Translate says that Сипуховые means "swan". They're still owls. Abductive (talk) 09:39, 30 March 2019 (UTC)[reply]

Sub-headings

For the second time, I have fixed the sub-headings in this section so that subsections are nested under those to which they are direct responses e.g. (as currently numbered) "9.6.1 Comment" is one level lower than "9.6 Previous discussion", as the former is a comment on the latter, as can be seen in the version of the page before the subheading was inserted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:55, 29 March 2019 (UTC)[reply]

This continuous tinkering with headings, changing the meaning of the comments of users is a really bad idea (and a violation of the ban that applies here). The relevant edit makeas it clear that the user in question intends a heading at the same level as the others. The same with the other heading. The "as can be seen in the version of the page" is based on adding a meaning to indentation; in as far as there is anything in this (only the user in question might know this, and there is no indication that he was asked) the user corrected this by inserting the heading. - Brya (talk) 04:12, 30 March 2019 (UTC)[reply]

In what you describe as the "relevant edit", the editor moves the "Comment" heading from level three to level four. Which is exactly what I restored in my fix. Furthermore, the indentation in the comment preceding the heading is ::* and in the comment following the heading is :::* . Both comments pre-date the insertion of the heading. [On reflection, this sub-secion probably belongs on the talk page.] Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:52, 30 March 2019 (UTC)[reply]

You must be operating in a parallel universe: in this universe the user did not move a heading but only inserted a heading at the same level as all the other headings in the thread. You changed all the other headings (without any reason other than an apparent wish to show you can get away with violating your topic ban). And your comment about indentation may have meaning in your religion, but this does not necessarily have any meaning outside it. - Brya (talk) 17:34, 30 March 2019 (UTC)[reply]

Request for protect:Q179294

This page is being vandalized by User:Jesamsex and other IPs, socket puppets of User:Unypoly for a long time, by adding a duplicate Korean version article w:ko:환자 (역사) and separate other Asian language versions.--Zhxy 519 (talk) 01:38, 18 March 2019 (UTC)[reply]

Q56145599 means Eunuch public official. It is a subclass of eunuch. It is not vandalism. – The preceding unsigned comment was added by 2001:2d8:e08e:4f67::12ef:40a1 (talk • contribs) at 03:50, 20 March 2019‎ (UTC).[reply]

Please ban this IP. It should be no doubt a socket puppet of User:Jesamsex.--Zhxy 519 (talk) 02:42, 24 March 2019 (UTC)[reply]

@Zhxy 519: I don't hear arguments from you about the subject. Please can you repeat them? --Infovarius (talk) 14:49, 29 March 2019 (UTC)[reply]

Sorry I don’t get the “argument” you mean. And how do you mean to repeat it?—Zhxy 519 (talk) 02:38, 30 March 2019 (UTC)[reply]

@Zhxy 519: "Argument" in the sense of stating a case. You have asserted they are sockpuppets, but you haven't provided any evidence, or if you have neither Infovarius nor I can find it. - Jmabel (talk) 04:37, 30 March 2019 (UTC)[reply]

@Jmabel, Infovarius:Ah OK.

w:ko:사용자:Jesamsex. This blocked userpage in ko.wikipedia showing no doubt that Jesamsex is a puppet.
Whois showing above IP is from Korea, where Unypoly comes from.
Another Whois also comes from Korea, which is rolling back directly towards this page.

--Zhxy 519 (talk) 00:49, 31 March 2019 (UTC)[reply]

@Twotwo2019: Is your this edit meaning that you agree to merge both? --Liuxinyu970226 (talk) 02:52, 31 March 2019 (UTC)[reply]

@Zhxy 519: and I meant argument about equality of these subjects. To me, non-speaker of Korean, seems that both senses have right to exist. --Infovarius (talk) 10:48, 1 April 2019 (UTC)[reply]

There is no difference between the sock puppet’s work and the original one. He or she doing this for only mischief. I have already started a delete discussion in Ko.wikipedia. You can be more patient.
Even if in Korean these two are different, the sock puppet can’t move some many languages to only fit his minor one.—Zhxy 519 (talk) 00:44, 2 April 2019 (UTC)[reply]

@Zhxy 519: Hmm, why not? The very meaning of Wikidata items (and sitelinks in it) is to serve the most correct correspondence as possible. If you are afraid to lose some inter-links you can use redirects for restoring usual (but not very exact) linking. --Infovarius (talk) 09:00, 2 April 2019 (UTC)[reply]

Since even in Korean the sock puppets’ edits could be considered improper, I strongly doubt that if they really understand the content in other languages. Which means, they could be hardly capable of making edits to “serve the most correct correspondence as possible”.—Zhxy 519 (talk) 02:29, 3 April 2019 (UTC)[reply]

East Jerusalem

Hi, I have a problem with places located in the Israeli occupied territories, that is, the territories Israel has occupied since the 1967 war.

After 1967, Israel has unilaterally annexed part of East Jerusalem, this annexation is accepted by exactly 0 other countries. My 2 cents is that we should follow what the international community says, and therefore should not say that they are in Israel.

Comments? (It was partly discussed here Huldra (talk) 20:55, 18 March 2019 (UTC)[reply]

In these situations, we should include all the most relevant points in the data. I outlined many of the relevant issues on relating countries and territories and subdivisions at Wikidata:Project_chat/Archive/2018/10#Countries_and_their_subdivisions_and_territory. We need to be able to specify recognition, administration, claims, control, domestic status, subdivision structure source, etc. so that any relevant attribute can be queried. The difficulty is figuring out a data model. In the case of East Jerusalem, we must include the data that the area is administered, controlled, and claimed by Israel, and the data that it is not recognized internationally as being part of Israel. We need to establish a broad data model for dealing with this and the dozens of similar cases, rather than simplifying each situation to pick whichever side of the conflict is more popular among the people arguing the point at the moment. --Yair rand (talk) 04:29, 19 March 2019 (UTC)[reply]

Do not we already have enough qualifiers to represent both point of view?--Ymblanter (talk) 20:33, 19 March 2019 (UTC)[reply]

Thank you Yair rand, that was interesting. And yes, I absolutely agree; we should get a consensus for this, as it concerns all the articles in East Jerusalem (ie, quite a lot).

Actually, we are in a somewhat similar situation for the articles about the Golan heights: also occupied and annexed by Israel since 1967, while the international community still consider it a part of Syria.

To start with "the top" question, that is, what country they are in:

If (and it's a big IF) we have a country (P17) label, then we should have, say 2 answers;

first: Country A (with the subfield that this is according to the international community, with the exception of country 1, 2 and 3)

second: Country B (with the subfield that this is according to country 1, 2 and 3)

Or: We do NOT use a country (P17) label at all for these places, but only the territory claimed by (P1336) label. Then we will still need a field indicating who accepts the claim. Comments? Huldra (talk) 20:48, 19 March 2019 (UTC)[reply]

To clarify the relevant scope here: I'm talking about every territory held in every one of the 165 military occupations listed at w:List of military occupations plus all prior military occupations, all territorial disputes, every state with limited recognition (current and former), and so on. These must all share one broad model.

country (P17) can't be limited to detailing recognition, unless another property stores other data of how the area is related to countries (control, administration, etc).

Regarding recognition itself, the "international community" is too vague to use as a single point anywhere. The individual countries' positions would need to be listed. That would take up a lot of space, though, so perhaps recognition should be split into a separate item which could be referenced by qualifier. However, that might make it a bit harder to query, so it's not ideal... --Yair rand (talk) 22:07, 19 March 2019 (UTC)[reply]

I agree that the scope should be all present disputed territories; I am not sure that I agree that it should include all pasts form of disputes.

I think we absolutely need another property which included who support the claim. Otherwise we would show that, say 2 countries have the same claim to a territory, without (in the most extreme case) telling the reader that one claim is supported by every country on the planet - 1, the other claim is supported by 1 country. If we don't have a "qualifier", we would be giving each claim "equal weight", and in effect misleading our readers. Approximate numbers could be used, where the individual countries' positions could be listed as a sub property, Huldra (talk) 20:49, 20 March 2019 (UTC)[reply]

Approximating numbers seems like it would be subject to dispute. Why approximate when we can be precise about which countries in particular support a claim? Do you agree that we also should include information on which country actually governed an area at a particular time? For example, almost the entire world recognizes Taipei as being part of the People's Republic of China, although Taiwan (ROC) actually governs the area, and all countries that recognize it as being part of Taiwan also recognize Beijing as part of Taiwan, but we wouldn't want Beijing to have the exact same statements as Taipei. --Yair rand (talk) 00:56, 21 March 2019 (UTC)[reply]

Do we have a property or qualifier for what country has de facto control of a territory? - Jmabel (talk) 15:12, 21 March 2019 (UTC)[reply]

No, I don't think so. There probably should be, but it's quite a complicated thing. Is Autonomous Republic of Crimea (Q756294) a territorial entity controlled by Russia? Russia doesn't consider that administrative division to exist, as it considers the Republic of Crimea (Q15966495) to be the relevant subdivision, whereas Ukraine wouldn't consider itself the rightful government of Republic of Crimea (Q15966495), since it doesn't recognize that subdivision. There are also different degrees of "control". Is the territory run by the military, or does the country run a functioning civil administration for the area within the country's regular framework? In internal disputes by subdivisions, one side typically administers the area, but there are (usually) no militaries involved. In some areas, a military can control an occupied area without the country setting up a local government to properly administer it. "Control" and governance/administration are sort of separate things, but sometimes closely related. --Yair rand (talk) 00:13, 22 March 2019 (UTC)[reply]

@Yair rand: I think that would come down to what we consider acceptable citations for de facto control. But China presents a clear example: two governments both claiming the same territory de jure, with one in de facto control of the bulk of the territory, and the other in de facto control of the remainder (Taiwan and a few small islands in the South China Sea). - Jmabel (talk) 01:21, 22 March 2019 (UTC)[reply]

@Jmabel: While it is technically true that, for example, the United States was de facto in control of South Korea in 1945, I think that saying just that is insufficiently specific to have as the entirety of the statement (although that would be more specific than the kinds of statements we have now). Taiwan isn't just de facto controlling the islands, it is (in contrast to the 1945 South Korea situation) running a full civil administration there in the context of the country's regular governance. I think it's important to make the distinction. --Yair rand (talk) 07:23, 27 March 2019 (UTC)[reply]

@Yair rand: I don't know much about South Korea immediately after WWII, but certainly in Germany there was a period where the various allied powers established administrations that were the effective governments of their respective zones. - 15:26, 27 March 2019 (UTC) – The preceding unsigned comment was added by Jmabel (talk • contribs).[reply]

@Jmabel: If I understand correctly, in e.g. American-occupied Germany, the area was not considered part of the US (by the US or any other country), American law was not applied to the area, and the highest authority was a military government rather than a civilian one. It still seems to me like there should be a distinction between how the US controlled that area and how Taiwan controls its territory. I'm not sure those particular attributes show such a clear division, though. Some entire countries are run by their own militaries, and plenty of countries have dependencies with separated legal systems without that tending to work like cases like occupied Germany... --Yair rand (talk) 06:06, 2 April 2019 (UTC)[reply]

Re Germany: absolutely. Never de jure even under the laws of the Occupying Powers, but certainly de facto.

In China: both governments claim de jure rule over the whole of China, but it is very clear who controls what de facto. - Jmabel (talk) 15:36, 2 April 2019 (UTC)[reply]

Korea was supposed to be a United Nations trust territory (Q985073) back then but not materialized which was not really the same as the situation of some other discussed territory. C933103 (talk) 09:54, 2 April 2019 (UTC)[reply]

Incorrect Wikisource links

We have a number of items with links to Wikisource, for example:

which link to works about the subject of the item, not to an equivalent Author: namespace page.

How can we fix this? And how can we use an edit filter or similar to prevent recurrence? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:46, 18 March 2019 (UTC)[reply]

Fix by moving the Wikisource link to described by source (P1343)? Ghouston (talk) 22:08, 18 March 2019 (UTC)[reply]

and optionally create an article like Elliott, Stephen (Q28032076), although it seems like overkill for a one-paragraph encyclopedia article. Ghouston (talk) 22:53, 18 March 2019 (UTC)[reply]

You'd need to create the data item regardless in order to use described by source (P1343). Beleg Tâl (talk) 23:07, 18 March 2019 (UTC)[reply]

Not necessarily, Albigence Waldo Cary (Q18819010) already has such a statement that just links to Appletons' Cyclopædia of American Biography (Q12912667). Ghouston (talk) 00:03, 19 March 2019 (UTC)[reply]

Can described by source (P1343) have a URL qualifier? There's also described at URL (P973). Ghouston (talk) 00:09, 19 March 2019 (UTC)[reply]

@Ghouston: Albigence Waldo Cary (Q18819010) is set up incorrectly. The link to Wikisource is to a biographical article which will have its own publication data that need to be included. The person who is the subject of the article will not have publication data. So you cannot add a Wikisource link that way. It may seem like "overkill" to you, but unless the full information for the citation of the article is included, then citation data for the article cannot be pulled from the data item. See for example DGRBM-1870 / Oedipus (Q47507582), which contains full publication data allowing the linked article to be cited, by using the data in the corresponding data item. With all the publication data available in the data item, a Wikipedian wishing to cite the article could use a tool to generate the citation, without having to manually retype all of the data. --EncycloPetey (talk) 01:58, 19 March 2019 (UTC)[reply]

I'm not sure, isn't the described by source (P1343) on Albigence Waldo Cary (Q18819010) that sources Appletons' Cyclopædia of American Biography (Q12912667) not also a valid way of doing it? You can add another qualifier for the page number, and there doesn't seem to be any further publication data. Ghouston (talk) 02:41, 19 March 2019 (UTC)[reply]

The described by source (P1343) linking is correct, but not the link in the Wikimedia links section of the data item. There is a lot of other publication data: identity / title of the work in which the article was included, volume / pages in the volume, date of publication, and author of the article. This should all appear in a data item about the article, regardless of the article's length. Every published work gets its own data item, from Leo Tolstoy (Q7243)'s massive novel War and Peace (Q161531) to the 17-syllable Frog Poem (Q11411329) by Matsuo Bashō (Q5676). Length of the publication is irrelevant. --EncycloPetey (talk) 03:00, 19 March 2019 (UTC)[reply]

An aside: persons on Wikisource can be either in Author space (if they are authors) or in Portal space (if they are not authors), but never in mainspace (unless the person is themselves a written work). Beleg Tâl (talk) 23:07, 18 March 2019 (UTC)[reply]

This is true on most Wikisource projects, but not all. The German Wikisource puts its Author pages in the Main namespace instead of in an "Author:" namespace. E.g. s:de:Johann Wolfgang von Goethe --EncycloPetey (talk) 02:01, 19 March 2019 (UTC)[reply]

i would not say "they are incorrect" but that the ontology is not settled. subjects of encyclopedic articles are notable at wikidata, so a migration path from wikisource page to wikidata item would be nice. we need a systemic way of indicating "depicts" or "is the subject of article" statements. and a author / portal subject infobox at wikisource. Slowking4 (talk) 11:37, 19 March 2019 (UTC)[reply]

The ontology is not at issue. If we allow such links to a Wikisource biographical article from a Wikidata item for a person, then the system fails whenever we have two different articles about the same individual on the same Wikisource project. Only a single link to a particular project is possible from any given data item. So this method would say that "link to the article about the person, unless there is more than one article about the person, in which case, (pick one of them?) (do it differently somehow?)". Any proposed system that breaks that easily is untenable. --EncycloPetey (talk) 14:08, 19 March 2019 (UTC)[reply]

Sounds like Wikidata's issues with the different spaces on Commons are not a problem unique to Commons. - Jmabel (talk) 16:14, 19 March 2019 (UTC)[reply]

"Any proposed system that breaks that easily is untenable." = sounds like wikipedia. the ontology is the issue. the fact that wikisource does not have a convenient "depicted" page for wikidata is interesting. maybe wikidata should create such pages, either in wikidata or wikisource. sources for those depicted people would then be citations. chapters in works in wikisource are citations. do not know why you would consider them a data item. that is until you roll out wikicite. Slowking4 (talk) 13:32, 20 March 2019 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ The ontology is not "broken", the wikidata item just was linked improperly to the Wikisource page (not everyone is well acquainted with every Wikimedia Project!). This is not different than people accidentally linking the wrong items together across two wikipedias. Compare ACAB-1 / Bell, Alexander Graham (Q21508901), which is a properly formatted page for an Appleton Cyclopaedia article. Circeus (talk) 15:00, 24 March 2019 (UTC)[reply]

So, how can we fix this? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:58, 29 March 2019 (UTC)[reply]

Unlinking the items is a solution enough. Or create quick'n'dirty items about the articles themselves. Aside from the (likely) "mass edit" angle, it's not exactly a complicated situation at all. Circeus (talk) 02:49, 30 March 2019 (UTC)[reply]

Q925929 Leroy P. Steele Prize

Could someone remove all the 61 awardees of this award (P166). It allows me to restructure this award in its composite parts. Thanks, GerardM (talk) 18:26, 19 March 2019 (UTC)[reply]

When I know how to do it automagically I will do it myself but I will not make a bigger mess by introducing all the versions of the Steele Prize.. Thanks, GerardM (talk) 13:13, 28 March 2019 (UTC)[reply]

items for box-header and box-footer portal subpages

Just saw that we have at least ~400 items for portal header and footer subpages like Portal:Contents/box-header (Q17434151) and Portal:Japan/box-footer (Q15614596). And pretty much all of them have instance of (P31)Wikimedia portal (Q4663903) statements, along with corresponding descriptions in many languages (probably because they are in the Portal namespace). What would be the correct instance of (P31) statement here, Wikimedia template (Q11266439)? --Kam Solusar (talk) 16:51, 23 March 2019 (UTC)[reply]

Yes, though a new, separate item for templates not in template space may be useful here. Circeus (talk) 16:20, 27 March 2019 (UTC)[reply]

How to deal with incorrect data on external identifiers?

Sometimes external identifiers have incorrect data, to say nothing of unreliable yet widely indexed websites. As an example, the artist Katherine Porter (Q19276859) (born 1941), is most widely known as simply "Katherine Porter". Her correct middle name appears to be "Pavlis", as she is named "Katherine Pavlis Porter" in several editions of Who's Who in American Art, the cover of Noon Knives (2002), the 1963 Colorado College commencement program (her alma mater), and as suggested in the contact email at her official website. However, some websites and databases give the (probably incorrect) name "Katherine Page Porter", e.g. Skinner Auctions, invaluable.com and even the Getty Union List of Artist Names. The Getty list cites a 2003 query of Askart.com., whose current entry on "Katherine Page Porter" clearly refers to a different person (born 1903). I removed "Katherine Page Porter" from the "Also known as" label, but given that secondary sources have conflated Katherine Page and Katherine Pavlis, and thus perpetuated falsehoods, what's the best way to handle such data, given that "Katherine Page Porter" is now a plausible search term for the artist born 1941, even if incorrect? Is Wikidata a repository of all 'data' regardless of veracity, or is it better than that? -Animalparty (talk) 21:55, 25 March 2019 (UTC)[reply]

First, you contact them about their errors. And then, IMO, you don't add it here. Sometimes they create new pages for each entity, sometimes they keep it for one of the entities and create new ones for the others. If it already exists, again IMO, you would either delete it from WD, or at least use the depreciated feature. Lazypub (talk) 22:01, 25 March 2019 (UTC)[reply]

Especially if that external source is one which otherwise is considered very credible, or widely used, it might be useful to add the wrong data here, but giving it deprecated rank and a fitting reason for deprecated rank (P2241) qualifier. Ahoerstemeier (talk) 10:43, 26 March 2019 (UTC)[reply]

One may be a middle_name and the other a maiden_name that just happen to be similar, I have seen this situation before but some research on Familysearch usually cleared up which name was which, she may appear in the 1940 census and that may help clear up what her maiden name was. However, I agree to add it here and deprecate the value. This is the only way to let people know which is correct and which is wrong. If we only present the one we think is correct, when confronted with a different value, people will flip a coin to decide which is more likely to be correct. Of course add the qualifier "stated in" and the evidence you used to judge it more likely correct. See for example the one I just completed at Livingston Farrand (Q6659644) for the "date of birth". --RAN (talk) 17:01, 26 March 2019 (UTC)[reply]

It looks like her birth name was "Katherine Louanne Pavlis" according to her birth certificate. --RAN (talk) 18:06, 27 March 2019 (UTC)[reply]

Q321014 error

Can someone peek at A. P. Carter (Q321014) and explain a little bit better why I get the error message for the image. --RAN (talk) 17:02, 26 March 2019 (UTC)[reply]

Given that the name contain 'carte' it matches a regex that suggests to the user to use locator map image (P242) instead of the regular image property. ChristianKl ❪✉❫ 17:28, 26 March 2019 (UTC)[reply]

I added another exception in image (P18). Ghouston (talk) 00:39, 27 March 2019 (UTC)[reply]

And some more that I found in the constraint violations. That makes 23 exceptions to the constraint, so far. Ghouston (talk) 10:26, 27 March 2019 (UTC)[reply]

According to Help:Property constraints portal, "Constraints are hints, not firm restrictions". If this is correct, it shouldn't be necessary to list exceptions, particularly as there could be many more - people with the surname Carter, and place names (Carterton, Mapperley, etc.) and buildings in those places. It may be possible to improve the regex - "Carte de/des/du", "MapOf/Map showing/Map South" are all likely to be maps, but "Carter", "Maple" and "Mapp" are not. Peter James (talk) 21:00, 29 March 2019 (UTC)[reply]

Help on operating system constraint

I need help on the property constraint for operating system (P306). It should allow either instances or subclasses of operating system (Q9135), but should also allow the specific value cross-platform (Q174666). Daask (talk) 17:09, 26 March 2019 (UTC)[reply]

I think cross-platform (Q174666) relates to platform (P400), not to operating system (P306). Ghouston (talk) 10:46, 27 March 2019 (UTC)[reply]

operating system (P306) is really a more specific use case of platform (P400), and cross-platform (Q174666) is entirely appropriate for it too (indeed the wikipedia articles about computing platforms explicitly include operating systems in this context). Circeus (talk) 16:14, 27 March 2019 (UTC)[reply]

Of course operating systems are generally designed to be platforms, but I don't think there's anything to be gained by mixing operating system (P306) and platform (P400) on items about software. It just makes it harder to enter the data and query it. I think it's more consistent to use platform (P400) on items about software and operating system (P306) on items about devices. On items like Minecraft (Q49740), the platforms are a mixture of operating systems and games consoles, and splitting the operating systems into a different statement wouldn't be helpful. Ghouston (talk) 01:30, 28 March 2019 (UTC)[reply]

Isn’t it smarter to list the different supported platforms ? cross-platform (Q174666) is meaningless and can mean something between « several gaming platform » to « a platform like java who can run on multiple OSes ». author TomT0m / talk page 12:07, 28 March 2019 (UTC)[reply]

Yeah, I agree. But put them all in platform (P400). Ghouston (talk) 21:27, 28 March 2019 (UTC)[reply]

I've proposed this now at Property_talk:P306#Restrict_to_devices. Ghouston (talk) 22:01, 28 March 2019 (UTC)[reply]

Hill and mountain class structure

I've been working with summit data recently (instances of hill (Q54050) and mountain (Q8502)) and wanted to tidy up the class structure of these landforms a bit (they differed and as far as I have found there is no official difference between these terms - just various height based distinctions that aren't agreed upon). Previously hill was a subclass of landform (Q271669), but not an instance of. Meanwhile mountain was an instance of, but not a subclass.

I've just changed hill to match mountain, as it made sense to me that these items should be instances of something. However, on further thought I'm thinking they should both be subclasses and not instances at all. Does this sound correct?

Another point I find a little confusing is that mountains are subclasses of summit (Q207326). Currently hills aren't - and both items have summit listed in has part(s) (P527). Something seems incorrect there to me. --SilentSpike (talk) 22:49, 26 March 2019 (UTC)[reply]

Subclasses of landform (Q271669) seems right, since clearly they have instances of their own. Mountains should not be subclasses of summit (Q207326). - Jmabel (talk) 23:01, 26 March 2019 (UTC)[reply]
- Okay, this matches up with my thinking too. I posted here mostly as a sanity check in case I was unaware of some technical definition that meant mountains are summits. Will implement these changes and if anyone disagrees with them let us know here. --SilentSpike (talk) 23:15, 26 March 2019 (UTC)[reply]
  - @Infovarius: I invite you to join the discussion here on mountain class structure (as I see you reverted the removal of summit sub-classification). --SilentSpike (talk) 17:44, 28 March 2019 (UTC)[reply]
Choosing instance/subclass of landform (Q271669) depends on understanding what landform (Q271669) is. If it is "type of form" then this is metaclass and mountain can be instance of it. Though it seems not the case now. As for summit (Q207326) (which is like "local maximum of height" for me), it seems natural for me to have hill (Q54050) and mountain (Q8502) subclasses of it. Why not, Jmabel? --Infovarius (talk) 15:36, 29 March 2019 (UTC)[reply]
- At least in English, a "summit" is a peak (highest point or locally highest point). A mountain has a summit (in some cases it can even have more than one, with one being the highest), but that doesn't mean it is a summit. Clearly the lower reaches of Mount Rainier, kilometers away from the highest point, aren't part of a summit. - Jmabel (talk) 15:55, 29 March 2019 (UTC)[reply]
- I also think of a summit as a separate entity from the hill/mountain itself - here in the UK they often have different names from each other. Plus they are distinguishable in language: "We made it to the summit of the mountain". However, reading the English wikipedia page for summits does make me question whether the geographical definition of a hill/mountain makes it equivalent to the summit itself. --SilentSpike (talk) 11:52, 30 March 2019 (UTC)[reply]

Relation between the two

Something else worth discussing is how to model the relation between the two. As there is no globally recognised difference (at least that I have found in my research) then any instance of one can be said to be the other. --SilentSpike (talk) 11:52, 30 March 2019 (UTC)[reply]

Telegram bot

Usage scenario

Inline Telegram bot similar to @wiki, but for Wikidata: https://telegram.me/wkdt_bot.

Usage examples

Search for Q-items:
@wkdt_bot telegram
Search for P-items (properties):
@wkdt_bot -p part of
Search for L-items (lexemes):
@wkdt_bot -l google

-- Luitzen (talk) 07:29, 27 March 2019 (UTC)[reply]

P463 (member of) and Q1439921 (list of regicides of King Charles I)

The use of member of (P463) for list of regicides of King Charles I (Q1439921) seems a bit odd (it doesn't seem to be "organization or club", as the property says; see Oliver Cromwell (Q44279) for an example). Are there no better properties to use? And should list of regicides of King Charles I (Q1439921) really be an instance of Wikimedia list article (Q13406463)? --Njardarlogar (talk) 07:53, 27 March 2019 (UTC)[reply]

"Regicides" is kind of a weird word usage here. It should probably be instance of (P31) signatory (Q28008347) of (P642) Death warrant of King Charles I (Q19756605). Circeus (talk) 16:08, 27 March 2019 (UTC)[reply]

member of (P463) list of regicides of King Charles I (Q1439921) is not useful, because list of regicides of King Charles I (Q1439921) in itself doesn't give any indication of what the set in question means. The value of P463 should be a substantive item (ie an actual organisation of club), not a list-type item, which is a different sort of item.

instance of (P31) signatory (Q28008347) is also unhelpful, because a person should only have instance of (P31) human (Q5). All other information about the person should be conveyed by specific properties.

One possibility would be to use participant (P710) with a new item "signing of the death warrant of Charles I", qualified by subject has role (P2868) = signatory (Q28008347).

significant event (P793) could also be an alternative. (Do we have any hard-and-fast rules for preferring one or the other of P710 and P793 for events involving people?)

Pinging @Andrew Gray:, to see if he has any thoughts. Jheald (talk) 21:36, 27 March 2019 (UTC)[reply]

@Jheald: I think when I added these it was showing as "member of: regicides of Charles I", ie the item was about the group, and has since got converted back into a list. But it's been a while and I don't really remember.

I suspect I went with member of (P463) because this is a definable group of people and they're a member of it. One problem with participant (P710)/significant event (P793) is that we have a lot of well understood but informal groups of people like this, and they're not always defined by something they "participated" in, or by an "event". See, eg, Berkeley Mafia (Q4354584) or Wolseley ring (Q724756), neither of which would be well-described using participant (P710)/significant event (P793). member of (P463) seems a lot more natural, constraints notwithstanding, and I wonder if the more appropriate method would be to loosen those constraints to include groups like this.

Poking around other similarly informal groupings, Disney's Nine Old Men (Q241920) and traitorous eight (Q1883987) have everyone connected using part of (P361), which is another possibility for groups. But it seems odd to have two different properties for the same basic concept purely depending on whether we identify the target item as an "organisation" or not - there will be many potential groups where it's borderline. Andrew Gray (talk) 00:06, 28 March 2019 (UTC)[reply]

PS: @Circeus:: it is a bit of an odd word, I grant, but it's also the one pretty much universally used by historians for this particular group of people, so I feel we should definitely retain it as a label if possible. Note that they didn't all sign the death warrant, some were involved in various other ways. Andrew Gray (talk) 00:09, 28 March 2019 (UTC)[reply]

Thinking back on this, I think part the issue has more to do with the unusual list nature of the main article more than the semantics of it. There is a group that can be conventionally defined. It just happen to be in a list format on Wikipedia, because they are connected to an event rather than an organization. It would probably be a not unreasonable option to actually switch the item title back to "Regicides of King Charles I", which is certainly less awkward when used with part of (P361). Circeus (talk) 18:19, 2 April 2019 (UTC)[reply]

Severe problems editing Wikidata

Tracked in Phabricator
Task T219364

part of a screenshot showing the issue - Andre Engels (talk)

Hoi, I just added an item Q62519158 and, I cannot use it in this form editing a related item. In effect it means that not only does query not work it is now also impossible to reliably edit based on the Q item itself. This means that the usability of Wikidata is severely compromised. Thanks, GerardM (talk) 08:27, 27 March 2019 (UTC)[reply]

Hello @GerardM:,

Can you give us more detailed information about what you tried to do? As far as I understand, you created Sigal Lahav Scher (Q62519158), added some statements, and then you wanted to use this item as a value in another item? Which one? What did go wrong? Did you get an error message? Lea Lacroix (WMDE) (talk) 08:52, 27 March 2019 (UTC)[reply]

Having the same problem with David Verey (Q62519569). I am trying to add him as spouse in Rosemary Verey (Q2166949), but when I fill in 'Q62519569' as the target there, I get 'No match was found'. - Andre Engels (talk) 08:57, 27 March 2019 (UTC)[reply]

There were a few publications I created with a tool. I wanted to link them by hand (tools fail me) and I cannot reply to an ORCID tweet as a result. It seriously sucks. What is the plan? Thanks, GerardM (talk) 09:03, 27 March 2019 (UTC)[reply]

What the issue seems to be to this layman's eyes is that new pages are not being added to the search database any more. - Andre Engels (talk) 10:11, 27 March 2019 (UTC)[reply]

It seems OK up to Optimisation of quantum dot infrared photodetectors (QDIPs) for imaging applications (Q62518560), but not for p-doped 1.3μm InAs∕GaAs quantum-dot laser with a low threshold current density and high differential efficiency (Q62518561) or later. Ghouston (talk) 10:14, 27 March 2019 (UTC)[reply]

The issue seems to have been repaired for new creations, but not yet for the elements previously affected. - Andre Engels (talk) 11:37, 27 March 2019 (UTC)[reply]

Per the phab ticket, the catching up is in progress but could take a few days. ·addshore· ^{talk to me!} 13:45, 27 March 2019 (UTC)[reply]

Sitelinks to Wiktionary

I just tried to make a sitelink to wikt:nitrox on the page nitrox (Q898391) without success. What's the secret code to use, and why does the interface need it anyway (the box is labelled "Wiktionary")? --RexxS (talk) 14:24, 27 March 2019 (UTC)[reply]

You need to add the language code of the Wiktionary you want to link to. - Andre Engels (talk) 14:34, 27 March 2019 (UTC)[reply]

Thank you. I just reached the same conclusion by using WDQS to find some items that had Wiktionary links and inspecting them. It really does need some better documentation – Help:Sitelinks doesn't even mention Wiktionary at all. Cheers --RexxS (talk) 14:38, 27 March 2019 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ So now I get this warning:

"Warning: Wikidata's notability policy does not allow links to Wiktionary entries unless the interlanguage links cannot be automatically provided. By clicking on "save", you confirm that this is the case. In general, connecting Wiktionary words to Wikidata concepts is not correct"

What on earth is all that about? I thought the whole point of having sitelinks on Wikidata is to provide interlanguage links for other sister projects? What does "unless the interlanguage links cannot be automatically provided" mean? The interlanguage links don't get created by magic, so they are never going to be "automatically provided". Why is it so difficult just to get a link from en:nitrox to wikt:nitrox? --RexxS (talk) 14:48, 27 March 2019 (UTC)[reply]

Hello,

I think the page Wikidata:Wiktionary/Sitelinks can bring some answers to you. Basically, the Wiktionary sitelink box was not made to connect concepts on Wikidata to Wiktionary pages, but only to connect pages outside the main namespace (for example Help:Contents (Q914807). A link to a Wiktionary entry should not be linked on a Q-item on Wikidata, since Q-items are about concepts and Wiktionary pages are about words, which are two different things. If you want to connect a Wikipedia page to a Wiktionary page, you can use Wikipedia's local "in other projects" template, that would be placed in the content of the page. If you have more questions, feel free to ping me. Lea Lacroix (WMDE) (talk) 14:55, 27 March 2019 (UTC)[reply]

Hi Lea, thanks for the response. If the Wiktionary sitelink box was not made to connect concepts on Wikidata to Wiktionary pages, then what was it made for? The sitelinks part of a Wikidata entry only has functionality in the context of making links between sister projects. If someone is reading an English Wikipedia page on en:Berlin, they will see in the "in other projects" section (above the language links in the left-hand column) links to Commons, to Wikinews, to Wikiquote, and to Wikivoyage – all automatically provided from Wikidata. There is no need for an '"in other projects" template' because we use Wikidata. But by your logic, a link to a Wikinews entry should not not be linked to a Q-item on Wikidata, since Q-items are about concepts and Wikinews pages are about news stories, which are two different things. I can level the same argument to Commons, which is about media; to Wikivoyage, which is about travel destinations and so on.

You have missed the point: we need the purpose of sitelinks on Wikidata to be functional and to link related items, not identical items. Of course items on Wiktionary are going to be words, not concepts, by the definition of a dictionary. In just the same way, items are Wikivoyage will be concrete destinations not concepts.

In this case, striving for some sort of inconsistent rigour (presumably because you're all currently preoccupied with the difference between concepts and lexemes) by insisting that we can't link a concept to its related definition on a particular sister site, has no practical effect other than to cripple the functionality of Wikidata in handling inter-site links for one sister project. Please rethink your stance on this. --RexxS (talk) 15:55, 27 March 2019 (UTC)[reply]

I think the goal is to eventually link wiktionary entries with the Lexeme space, but they haven't figured out how to do that yet. Circeus (talk) 15:58, 27 March 2019 (UTC)[reply]

@RexxS: This is very old news and was much discussed here and on the Lexicographic Data page. If you were to take a look at a handful of lexemes you would see that there are frequently multiple "senses" which link to Wikidata items for a given lexeme, and conversely there are multiple lexemes that can link to a single Wikidata item. The concept/word linkage is intrinsically many-to-many even within a single language, and the Wikidata sitelink mechanism simply cannot handle that. ArthurPSmith (talk) 19:21, 27 March 2019 (UTC)[reply]

@RexxS: I’m sorry, but I think it’s you who are missing the point. The Wikimedia Commons page for Leonardo da Vinci is still a page about Leonardo da Vinci (Q762), though focused on his work as an artist. His Wikiquote page is also about that same subject, now focusing on a different aspects, his quotes. The Wikivoyage page about Prague and the Wikipedia article of the same name are also the same subject (the capital city of the Czech Republic), though viewed through different lenses, so to speak (travel guide and encyclopedia). And Wikinews articles are indeed rarely about the same subject as other items, that’s why they usually get linked to separate items (random example: Q57630492).

Wiktionary works differently: a single Wiktionary page contains information for multiple languages, each possibly listing multiple words (e. g. homographs), and often with several meanings per word. Would you link stress to stress (Q123414), mechanical stress (Q206175), or stress (Q181767)? Is handy a mobile phone (Q17517) (German) or a handjob (Q1480864) (English)?

The Wikidata team already worked on a different solution for Wiktionary sitelinks: Cognate. Trying to tie Wiktionary pages to Wikidata items is terribly wrong on a conceptual level. (And no, Lexemes are not a replacement for Cognate, because Wiktionary pages don’t correspond to Lexemes either.)

And specifically in response to If the Wiktionary sitelink box was not made to connect concepts on Wikidata to Wiktionary pages, then what was it made for? – Léa already answered that: it’s for pages outside the main namespace, such as help pages, project pages, templates, or modules. Those are the parts of Wiktionary that can be linked to Wikidata items and pages on other wikis. —Galaktos (talk) 21:26, 27 March 2019 (UTC)[reply]

@ArthurPSmith, Galaktos: I couldn't care less how old the news is. The problem remains and you offer no solution. Let me make this clear: lexemes have nothing to do with making a sitelink from English Wikipedia to Wiktionary.

I assure you I haven't missed any point. The English Wikipedia page en:Leonardo da Vinci is a narrative summary of his life and works; the Commons page c:Leonardo da Vinci is a gallery of images (and potentially other media) illustrating his work. If as Lea claims, the Wikidata page, Leonardo da Vinci (Q762) is about the concept of Leonardo da Vinci, then it's abundantly clear that those are just as different from one another as the words Leonardo da Vinci are.

Have you ever visited Wiktionary? The wikt:Main page starts with the words "Welcome to the English-language Wiktionary", not "the multi-lingual Wiktionary", nor "the combined German and English Wiktionary". Each page contains a dictionary definition in precisely one language, and there is absolutely no reason why any unambiguous term should have a link to each and every site where that term exists.

I'm not asking how I would link wikt:stress to a wikidata item. I'm asking why I can't link the article en:Nitrox to its dictionary definition wikt:nitrox – an exact one-to-one relationship. You've offered no explanation of how that is not feasible or why that is not allowed.

Cognate is jam tomorrow. I've been using Wikidata for over seven years productively, and I've yet to see any convincing explanation of why inter-site links have to exclude Wiktionary's mainspace. I understood that Lea thinks "Basically, the Wiktionary sitelink box was not made to connect concepts on Wikidata to Wiktionary pages, but only to connect pages outside the main namespace (for example Help:Contents (Q914807)." but that is simply an assertion, not an argument, and it doesn't address the question of why the functionality exists if we're not allowed to use it. --RexxS (talk) 22:12, 27 March 2019 (UTC)[reply]

@RexxS: I’m sorry, but this is ridiculous. Have you ever looked at a Wiktionary page other than the main page? “the English-language Wiktionary” means that it is written in English, not that it is about the English language exclusively. Go to wikt:a and you will see entries in over a hundred different languages, all on one page. I really don’t understand how you can possibly claim that [e]ach page contains a dictionary definition in precisely one language. —Galaktos (talk) 22:52, 27 March 2019 (UTC)[reply]

@Galaktos: Ridiculous is it? Take a look at the very page I've quoted to you as needing a link from the English Wikipedia: wikt:nitrox - the full url is https://en.wiktionary.org/wiki/nitrox and note the "en" in the url. Nothing there in a hundred different languages. Look at the left sidebar. There's a set of "in other language links". There are two links: to https://hr.wiktionary.org/wiki/nitrox the entry for nitrox on the Croatian Wiktionary and https://ru.wiktionary.org/wiki/nitrox the entry for nitrox in the Russian Wiktionary. Yes I know that they only exist because they are written in Croatian and Russian, but it doesn't matter which one you look at, they provide a dictionary definition of the concept of nitrox. The related item on Wikidata is still nitrox (Q898391), the related article on English Wikipedia is en:Nitrox and the related article on Russian Wikipedia is ru:Нитрокс (дайвинг) in every single case. What is so problematical about making them link to each other using the very mechanism that Wikidata provides? --RexxS (talk) 23:23, 27 March 2019 (UTC)[reply]

@RexxS: While it might be correct that in this particular case there's only one page on En.Wikidictionary, there will be many cass where there are multiple matching pages. ChristianKl ❪✉❫ 11:15, 28 March 2019 (UTC)[reply]

Indeed, ChristianKl, and I can see good reason why we would not want to link to those cases. But the analogy is the Bonnie and Clyde (Q219937) problem. It's obvious that we shouldn't create the interlanguage links to all three of Bonnie and Clyde (Q219937), Bonnie Parker (Q2319886), and Clyde Barrow (Q3320282) for every article about any of them, but we don't put a blanket prohibition in making the links where there is a one-to-one relationship between one of the items and a corresponding article in a Wikipedia. So it should be with Wiktionary: not every entry has a one-to-one relationship with an an article in a language Wikipedia, and so we shouldn't link them. But for the cases where that one-to-one relationship exists, it insults the editor's intelligence not to allow them to make use of a facility that the software has built-in. --RexxS (talk) 16:14, 28 March 2019 (UTC)[reply]

The current goal is to have sooner or later sitelinks that go from lexemes (or senses) to Wikidictionary pages which then results in a good solution. If we add a bunch of links from the Q-namespace to pages like https://en.wiktionary.org/wiki/nitrox that will make it later more complicated to get the proper links later in place. ChristianKl ❪✉❫ 17:20, 28 March 2019 (UTC)[reply]

@RexxS: This is WikiMedia, it is all a work in progress. Yes it's related to the "Bonnie and Clyde" problem that would be nice to solve for Wikidata and its sitelinks - but it's much much worse in the Wiktionary case. Wiktionary pages are not structured data, they are a mish-mash of languages and parts of speech and etymologies. Lexemes in Wikidata are designed as structured data for words, and we have a mechanism for interlinking them with Wikidata items, so that's progress. Conceivably Wiktionary pages could be redesigned to draw from Wikidata lexemes, and so the links you desire would eventually be there. But as with enwiki but perhaps more so, it's been hard to make progress on integration. Lydia and the developers may have something more concrete in mind going forward that I'm not aware of of course. This fall's Wikidatacon is going to be talking a lot about languages and lexemes, so if you have concrete ideas you can propose something there. ArthurPSmith (talk) 11:46, 29 March 2019 (UTC)[reply]

State of the art of the commons category problem

I’m translating the question on Commons category on the FAQ : Help:FAQ#Other_Wikimedia_sites and it seems to me that this remains kind of mess. Question : is this the best we can do right now or is this the result of the history of Wikidata and should now be simplified one way or another ?

Notified participants of WikiProject Commons author TomT0m / talk page 18:04, 27 March 2019 (UTC)[reply]

@TomT0m: The Commons category point was added quite recently by @Ghouston:, [2], and seems reasonable to me - the important thing nowadays is to add the commons sitelink so that the Wikidata information can be used in the Commons category. Thanks. Mike Peel (talk) 18:57, 27 March 2019 (UTC)[reply]

There’s 3 different models for the same kind of information. Is not it a bit much ? author TomT0m / talk page 19:01, 27 March 2019 (UTC)[reply]

The text could probably be simplified. The sitelink goes in the topic item unless topic's main category (P910) exists, in which case it goes in the category item, but Pi bot will move it over to the category item if needed. I'm hoping that Commons category (P373) can be deprecated later this year, as >95% of the time it just duplicates the sitelink now, but the remaining edge cases need to be sorted out (anyone interested in helping to clear Wikidata:Database reports/Constraint violations/P373 and Wikidata:Database reports/Complex constraint violations/P373?) Thanks. Mike Peel (talk) 20:31, 27 March 2019 (UTC)[reply]

The pragmatic consensus based solution. Seems to work just find. Not worth starting yet another fruitless discussion to change it. I'm not in favour of deprecating Commons category (P373). It has quite a few downstream users.

With structured data on Commons the whole landscape will change anyway. I would keep an eye on that if you want to change things. Multichill (talk) 20:33, 27 March 2019 (UTC)[reply]

@Multichill: The current system is a pain since it requires two copies of the data - one in Commons category (P373), the other in the sitelink - and they have to be kept in sync. The sitelink allows access to Wikidata from the Commons categories, and it also auto-updates when a category is moved, which is why I'm hoping we can migrate to that fully in the future. There are solutions for downstream users, such as the code in en:Module:WikidataIB that is now used in en:Template:Commons category to use the sitelink in preference to P373, and I hope that we can migrate users to that over time. This may all change with structured data on commons, but it's not there yet. Thanks. Mike Peel (talk) 21:00, 27 March 2019 (UTC)[reply]

The purpose of deprecation is to leave time to clients to adjust. If we’re not deprecating things just because there is client it’s just useless to deprecate anything at all — no need to adjust anything if nothing changes :) If we reason like this on anything on Wikidata we’ll never change anything, or maintaining compatibility will soon become a big burden. author TomT0m / talk page 21:01, 27 March 2019 (UTC)[reply]

Given that a PfD was only just closed on this, I don't see any value in opening this up again after a mere three weeks. Come back in six months time, or a year, and see if things have changed. Jheald (talk) 21:19, 27 March 2019 (UTC)[reply]

@Jheald: See my comment in that deletion discussion. Most of the !votes in that discussion were based on old information, things have already changed in practice but the people commenting there haven't caught up yet. Above I said "later this year" - about six months time sounds right. Thanks. Mike Peel (talk) 21:24, 27 March 2019 (UTC)[reply]

Are the comments I made on that deletion discussion out of date? I'm not sure that anything has changed since then. Ghouston (talk) 00:58, 28 March 2019 (UTC)[reply]

@Ghouston: Yours were relatively up-to-date (you've been following the practical changes over the last year!). I think there's consensus nowadays to just create a category item if a gallery sitelink is blocking it from the topic item, but that's not yet updated in the notability guidelines. The other main point you raised is still valid, I've asked about that at Wikidata:Contact_the_development_team#Using_commons_sitelinks_rather_than_P373_in_the_sidebar?. Thanks. Mike Peel (talk) 19:29, 29 March 2019 (UTC)[reply]

A lot of partners

A question asked on frwiki : there is a lot of (work) partners (partner in business or sport (P1327) ) for this person. It seems there are two kinds of collaborations involved, apparently (two fields of work), and there is a grouping/filtering according to some field of work value for the partnership. Is there a known solution on Wikidata to help build this, like using field of work (P101) as a qualifier ? Or the opposite, to qualify « field of work » with the partners

⟨ Herbert ⟩ field of work (P101) ⟨ Tennis ⟩
partner in business or sport (P1327) ⟨ Mahut ⟩
partner in business or sport (P1327) ⟨ … ⟩

(maybe not the right one since each partnership can have a begin and end date)

PS: do we have a dedicated wikiproject for this kind of question ? I found the obsolete WD:WikiProject Infoboxes/persons and Wikidata:WikiProject Biographies which is not a fit either (redirect to an identifier project). author TomT0m / talk page 18:37, 27 March 2019 (UTC)[reply]

(it seems that actually there is some usage for this qualifier :

select distinct ?prop ?qualifier ?qualifierLabel {
  ?prop a wikibase:Property 
          ; wikibase:claim ?stProp
          .
  []    ?stProp [?qual []]
        .
  ?qual ^wikibase:qualifier ?qualifier .
  
  values ?stProp { p:P1327 }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

Try it!

) — created a template to query the qualifiers used to qualify statements used with a property, {{Qualifier used for}} author TomT0m / talk page 19:56, 27 March 2019 (UTC)[reply]

Any efforts on making some more advanced query-generator for wikidata?

Hi everybody,

the standard-query-builder (query.wikidata.org) is great thing to begin exploring Wikidata. Are there any projects for a more advanced query-bulder, where one can expand edges/relations and filter values (property x > some value) without knowledge of the query language?

Cheers, Datawiki30 (talk) 21:21, 27 March 2019 (UTC)[reply]

Hello,

Yes, it is in the roadmap of the development team for this year. Lea Lacroix (WMDE) (talk) 09:28, 28 March 2019 (UTC)[reply]

Data model intent on ranking and Wikidata documentation on it contradiction

Quoting mw:Wikibase/DataModel#Ranks_of_Statements

Preferred statements refer to the most important and most up-to-date information that should be used per default in most contexts (example: only most recent population figures for Berlin would be shown in the Wikipedia infobox for Berlin). Note that there may be multiple preferred statements. This may imply a multi-valued property (e.g. a person's children), or a disagreement (diverging population figures given by different sources).

Quoting Help:Ranking : « The item for Barack Obama has two values listed as children; both values should be given the normal rank because neither value is more "correct" than the other »

It’s an inconsistency. How do we solve this ? author TomT0m / talk page 11:48, 28 March 2019 (UTC)[reply]

I think the example of multiple children being "preferred" is relevant only if there are other values to which these need to be preferred. Equally valid multiple values, like single values, are normally "normal". - Jmabel (talk) 15:08, 28 March 2019 (UTC)[reply]

Does not make a lot of difference in practice indeed if there is no other information, but your interpretation is contradicted by the Normal rank description in the data model document Normal statements contain relevant information that is believed to be correct but that may be too extensive for showing it by default (example: historic population figures for Berlin for many years).. The children are really neither. However one application could be that in crowded infoboxes we could exclude by default normal rank informations. I know in frwiki for example Wikidata infoboxes offers a way to disactivate one field of data present on Wikidata if a contributor feels like it’s not really a relevant information. author TomT0m / talk page 17:16, 28 March 2019 (UTC)[reply]

Again, "normal" is… normal. In most multi-value cases, where all values are equally appropriate and all shown, they are all marked as "normal". "Deprecated" indicates there is something wrong with the particular value. So if we need to distinguish "here are a bunch of valid values, e.g. some of them historical, but there are too many to show routinely," then we mark the ones that are worth showing as "preferred" and leave the others that are true but not equally useful as "normal". - Jmabel (talk) 19:31, 28 March 2019 (UTC)[reply]

@Jmabel: We don’t really understand each other. I don’t really see an answer to my question in your statement, so it remains, but whatever, I guess this is not a big deal. I don’t really take back what I said about a potential use case however. Not really thinking about the fact that there is actually multiple value in a particular case could be valuable. I mean, if we consider there is a « main » child (say child1 (whatever that means, probably not the best example) for a person (say person1) with multiple value for the « child » property (say child2 and child3), and we decide child1 should be preferred and child2 and child3 should be « normal ». If we have another person2 with only one child child4. By your rule, child4 should be « normal », but what if it’s in exactly the same position relative to person2 that child1 is to person1. We could use « preferred » rank to indicate that, and a Wikipedia could choose to use only the values indicated as « preferred » in its person infobox because it aims to be parcimonious, and we know the criteria that implies the child is on « preferred » rank, and it do not really want the « normal » one in its infobox — again, just a (bad and un-thought of) criteria, but say we choose the « main » children are those raised by the person and not those he did not even know he had, if he’s a man. The advantage is that it’s a consistent rule, the rank does not depend on the fact that there is actually something to rank. And the definition of « normal » is in that spirit, it does not refer to the fact that there are other values, it depends on the fact that it may not be chosen in an infobox. On the example, we may not want to rely on the number of children to choose not to show the children unknown to the genitor, and not show unknown children in the infobox of the genitor even if it’s his only child. author TomT0m / talk page 20:04, 28 March 2019 (UTC)[reply]

@Jmabel, TomT0m: I am pretty sure that the paragraph written about preferred rank after a long discussion of a specific case related to children listing. This is a bad idea to use example in the definition, an example should come after the definition.

We can have a list of three children with two defined as preferred rank and one considered with normal rank if there is a parmeter allowing to distinguish the different children. One can be the authority of the source defining the filiation: if several recognized sources mention that a person X has 2 children and one obscure source mentions 3 children then to take account of the obscure source without promoting it, it can be worth to use rank to distinguish the quality of the sources. It can be used to distinguish other situations like illegitimate child especially when no legal way is available to confirm the filiation. Snipre (talk) 19:45, 29 March 2019 (UTC)[reply]

How long does a P1630 (formatter URL) change take to propagate?

Tracked in Phabricator
Task T112081

This morning I changed the formatter URL (P1630) for British Library system number (P5199) (diff), rewriting the old one with a new one, and the change seems to have propagated almost immediately -- within a few minutes at most.

But this afternoon I changed the formatter URL (P1630) for UK Parliament thesaurus ID (P4527) (diff), changing the rank of the old one to 'normal' down from 'preferred', and adding a new one with preferred rank -- but nothing seems to be changing.

Is there an issue here, or do I just need to be more patient? Jheald (talk) 19:16, 28 March 2019 (UTC)[reply]

Additional: Purging a page where the property is being used (ie adding ?action=purge on url) updates the url link to the now preferred option. (hat-tip & thanks to Andrew Gray)

But is this something that is having to be done manually? I am not convinced that, when P1639 is changed in the second way above, the signal is being sent out to pages where the property is being used that they need to be regenerated. Sometimes such a signal can take a while to propagate, which is okay, but here is it being sent out at all? Jheald (talk) 19:33, 28 March 2019 (UTC)[reply]

@Jheald: Indeed, at the moment entity pages aren’t updated when the formatter URL changes – that’s the subject of T112081. (Similarly, their RDF in the query service isn’t updated when a formatter URI for RDF resource (P1921) is edited either; I don’t think we have a task for that yet.) --Lucas Werkmeister (WMDE) (talk) 10:23, 29 March 2019 (UTC)[reply]

@Jheald, Lucas Werkmeister (WMDE): given that, shall I just knock together a script to purge all the affected pages over the next few days, or is there a more elegant workaround? Andrew Gray (talk) 22:00, 31 March 2019 (UTC)[reply]

@Andrew Gray: I’m not sure if I should encourage that (it sounds like a lot of extra server load), but I’m not aware of any better solution. How many pages (roughly) are we talking about? --Lucas Werkmeister (WMDE) (talk) 10:46, 1 April 2019 (UTC)[reply]

@Lucas Werkmeister (WMDE): ~5500, I think. I can spread it over a longer period or a few batches, rather than try and do them all in one rush. Andrew Gray (talk) 15:24, 1 April 2019 (UTC)[reply]

@Andrew Gray: okay, that sounds acceptable. (I think mw:API:purge doesn’t actually re-render the pages anyways, so that would be spread out to whenever each page happens to be visited the next time.) --Lucas Werkmeister (WMDE) (talk) 16:08, 1 April 2019 (UTC)[reply]

@Andrew Gray: If you've got a script, could you do the BL sysnums as well -- it seems I was overly-optimistic above, and their new formatter hasn't propagated either. Thx. Jheald (talk) 09:39, 2 April 2019 (UTC)[reply]

Awards not accepted

Do we record awards not accepted? (using award received (P166) or otherwise)

eg Yeshayahu Leibowitz (Q215927) and en:Yeshayahu_Leibowitz#Awards_and_recognition. Jheald (talk) 21:20, 28 March 2019 (UTC)[reply]

There was something about that at Wikidata:Project_chat/Archive/2018/08#Awards refused or returned, although not much discussion. Ghouston (talk) 22:12, 28 March 2019 (UTC)[reply]

Translation property

Hello wikidatans, I was looking for a property to check the langauges a work (ietm) is translated to. Does such a property exist? My search about translation properties did not yiel to sufficient results. If it does not exist I'd like to suggest it to be created. --Sky xe (talk) 00:01, 29 March 2019 (UTC)[reply]

@Sky xe: The only property I'm aware of is has edition, but that of course covers any edition or reissue, not just translated ones. The way it's being used is also quite random, with some editors indicating language using a qualifier, while others do not. Personally I think that what you're describing is a perfectly reasonable/very useful query scenario and would support a proposal if you make it. EDIT: to add to the confusion, I should mention that modified version of and derivative work are also sometimes used to "hack" the translation issue. There may be others as well, of course. EDIT2: edition or translation of deserves a mention of course, going in the opposite direction. Moebeus (talk) 00:26, 29 March 2019 (UTC)[reply]

For what it's worth, here's a query for the translations currently in Wikidata, looking for edition or translation of (P629) and a different language of work or name (P407) :

SELECT (year(?date) AS ?year) ?old_work ?old_workLabel (GROUP_CONCAT(DISTINCT ?old_lang_label; SEPARATOR = ' / ') AS ?old_langs) 
    (GROUP_CONCAT(DISTINCT ?new_lang_label; SEPARATOR = ' / ') AS ?new_langs)  ?new_work ?new_workLabel (year(?new_date) AS ?new_year)
         
WHERE {
  ?new_work wdt:P629 ?old_work .
  ?new_work wdt:P407 ?new_lang .
  ?old_work wdt:P407 ?old_lang .
  FILTER (?new_lang != ?old_lang) .
  OPTIONAL {?old_work wdt:P577 ?date} .
  OPTIONAL {?old_work wdt:P571 ?date} .
  OPTIONAL {?new_work wdt:P577 ?new_date} .
  OPTIONAL {?new_work wdt:P571 ?new_date} .
  ?new_lang rdfs:label ?new_lang_label FILTER(lang(?new_lang_label) = 'en') .
  ?old_lang rdfs:label ?old_lang_label FILTER(lang(?old_lang_label) = 'en') .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en,fr,de,it,es,nl,la,pl,ru,uk". }
  
} GROUP BY ?date ?old_work ?old_workLabel ?new_work ?new_workLabel ?new_date
ORDER BY ?year str(?old_workLabel) str(?old_work) ?new_year str(?new_workLabel)

Try it!

Jheald (talk) 09:18, 29 March 2019 (UTC) @Moebeus, Jheald: Thank you a lot for your answers. The work around to get the translations of a work seems to be not satisfying enough, as it does not easily answer questions as: "give me a list of most translated works" or "sort the languages based on translation counts of certain work (e.g. book)". I think it makes sense to judge the translation movement of important works with a direct subject -> property -> object format. I'll suggest it to be created and hope it will be accepted.[reply]

BTW: I would suggest the name "Translated to" (=language) to avoid ambiguity with existing properties. Would be glad and thankful for initial feedback! Sky xe (talk) 15:27, 3 April 2019 (UTC)[reply]

Do you know about Wikidata:Editing restrictions?

Started by User:Rschen7754? --Succu (talk) 22:28, 29 March 2019 (UTC)[reply]

Clearly part of the consensus reached on the linked discussion pages. Sjoerd de Bruin (talk) 08:41, 30 March 2019 (UTC)[reply]

Second line and language box

Hello. When you add media legend (P2096) you have to add the language. The problem is that when you are writing the legend the language box appears. And if you need two lines for the legend, then you can't see the second line because of the language box (you can not see what you are typing). The language box must be some mm lower. Xaris333 (talk) 08:19, 30 March 2019 (UTC)[reply]

I wonder why P2096 value should originally be languoid-less, can you explain more here? --Liuxinyu970226 (talk) 10:45, 2 April 2019 (UTC)[reply]

What is a "languoid"? - Jmabel (talk) 15:37, 2 April 2019 (UTC)[reply]

New accounts and QuickStatements

Quick question: are there any restrictions before new accounts can use QuickStatements -- eg account must have existed for a certain number of days, must have made a certain number of edits? Jheald (talk) 12:28, 30 March 2019 (UTC)[reply]

Account needs to be autoconfirmed, so 4 days and 50 edits. --Tagishsimon (talk) 17:02, 30 March 2019 (UTC)[reply]

Resolved Jheald (talk) 09:35, 2 April 2019 (UTC)[reply]

Inferring notability from external-id properties

Many of our external ID properties do not give an indication of notability (e.g. X username (P2002)).

A few, however do (e.g. JSTOR article ID (P888), under Wikicite), and several with sets in Mix'n'Match.

I have therefore created:

to be used in place of Wikidata property for an identifier (Q19847637). This will facilitate including, or excluding, people with a type of identifier from queries regarding notability (e.g "all humans with no links to other items, and no interwiki links, but exclude those with IDs that ~~confer~~ imply notability").

All properties that have the attribute eventually complete (Q21873974) should use Q62589316, but the inverse is not necessarily the case.

Please help by applying these items to external-ID properties, and by making use of constraints to make the most of their deployment. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:23, 30 March 2019 (UTC)[reply]

You should have discussed this first before having a bot tag a ton of properties with this. Adding the claims to properties like BAG building ID (P5208), Playboy Plus ID (P5346), IPv4 routing prefix (P3761) makes hits a poluted concept and very much biased to in the direction of expanding notability. This looks like a back door to get around Wikidata:Notability. Multichill (talk) 13:58, 30 March 2019 (UTC)[reply]

Please don't issue instructions (even retrospectively); and please remember to assume good faith. This is not in the least about "expanding notability", and our notability policy is unchanged by it. Please also note my comment about eventually complete (Q21873974); which applies to each of the examples you cite. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:03, 30 March 2019 (UTC)[reply]

I'm assuming good faith and improved the property so people don't get the wrong impression. Multichill (talk) 14:12, 30 March 2019 (UTC)[reply]

Accusing me of creating "a back door to get around Wikidata:Notability" is "assuming good faith"? Your change did nothing to improve Q62589316 (which is an item, not a property), as "suggest" is a synonym for "imply". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:19, 30 March 2019 (UTC)[reply]

I don't see any instructions or accusations being thrown around here. In the interest of keeping things civil, could you explain why eventually complete (Q21873974) implies Wikidata property for an identifier that suggests notability (Q62589316)? As I'm not sure I see that this is necessarily true for all cases (see mix n' match where many entries are marked as not applicable to wikidata) --SilentSpike (talk) 15:02, 30 March 2019 (UTC)[reply]

"You should have...". Q21873974 means that we will create an item for every valid entry in the database concerned. An item marked "not applicable to wikidata" will clearly not have a value for the respective ID in Wikidata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:14, 30 March 2019 (UTC)[reply]

I suppose I am conflating two different ideas (not applicable + not notable). --SilentSpike (talk) 15:28, 30 March 2019 (UTC)[reply]

grumble break all my queries why don't you grumble Jheald (talk) 14:50, 30 March 2019 (UTC) [reply]

You seem to have mistyped "allow me to improve". HTH. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:14, 30 March 2019 (UTC)[reply]

I don't particularly object to the idea, but is doing it through the instance-of/subclass-of tree really the best way to do it? It seems like it's going to get messy and confusing if anyone tries to do the same thing for a different facet in future (eg had we decided to do "eventually complete" in this way...). A property would seem cleaner. Andrew Gray (talk) 21:59, 31 March 2019 (UTC)[reply]
- I was half-way through drafting a property proposal when I realised these are sub-classes of Wikidata property for an identifier (Q19847637). I've no objection to switching, if there is consensus that a property is better. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:17, 31 March 2019 (UTC)[reply]

Listeria and long pages

Listeria sometimes produces very long pages. It it possible to instruct it to break at a given page size, and to create pages as, say, Foo (part 1), Foo (part 2), and so on? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:08, 30 March 2019 (UTC)[reply]

Currently Listeria only works on a single page between the two templates. You can use sections, but that doesn't really serves your purpose.

I usually end up splitting up the list myself by something that makes sense. For paintings it usually makes sense to split up by time period. So for example the Finnish National Gallery has a separate list for the 19th Century (more examples in Category:WikiProject sum of all paintings huge collections). Maybe something like this works for your case too. Multichill (talk) 15:31, 31 March 2019 (UTC)[reply]

Alternatively you could create multiple pages distinguished by different values of LIMIT and OFFSET. Jheald (talk) 17:03, 31 March 2019 (UTC)[reply]

Porn link in Q3070476

Property:P856 in Q3070476 points to a porn site. Apparently the old weblink has been re-used by a porn operator. What should we do with it? My suggestion is that we delete it completely as it does not add any useful information to the item. Csigabi (talk) 17:59, 30 March 2019 (UTC)[reply]

Have you looked whether archive.org has indexed the page? If so, we could link there insteadly. ChristianKl ❪✉❫ 19:59, 30 March 2019 (UTC)[reply]

Looks like that has now been done. Is there any way to kill the link that now leads inappropriately to a porn site? (I understand the need to keep the URL for the record, but is there any way to kill it as a live link?) - Jmabel (talk) 08:18, 31 March 2019 (UTC)[reply]

The correct thing is to set an end date. Whatever application one builds can take this in account. Wikidata doesn't or shouldn't delete information that doesn't fit a presentist POV. --- Jura 10:20, 31 March 2019 (UTC)[reply]
- End date is there, but so is a live link to a porn site. What would happen if someone similarly took over a URL and had a site with malware? I think we ought to have some mechanism by which we can prevent a live link in situations like this. - Jmabel (talk) 17:36, 31 March 2019 (UTC)[reply]
  - @Jmabel, Csigabi, ChristianKl: Better continue the discussion there with the devteam (sorry, should have pinged but totally missed). Lydia gave a first answer and thinks the links on Wikidata are not directly consulted by most people, so it’s not much of a problem) author TomT0m / talk page 18:05, 31 March 2019 (UTC)[reply]
    - To clarify: my point was that most people consume Wikidata's data through other tools and services. So if we solve it locally here in the Wikidata UI then we've only solved a very minor part of the problem. --Lydia Pintscher (WMDE) (talk) 17:35, 2 April 2019 (UTC)[reply]

Predicato onomastico vs Particella nobiliare - should they be merged?

It seems to me that nobiliary particle and nobility predicate are covering the same subject, but two distinct wikipedia articles in Italian are blocking a merge. If someone with better italian skills than me could have a look, that would be great. If the distinction in Italian is in fact great enough to warrant two articles, the english labels need to be edited to avoid confusion, I think. Moebeus (talk) 18:24, 30 March 2019 (UTC)[reply]

Merging duplicated scientific articles

Compact binary merger rates: comparison with LIGO/Virgo upper limits (Q59452696)

Compact binary merger rates: comparison with LIGO/Virgo upper limits (Q59452694)

Is it safe to use merge.js to do the merging ?
How did it happen in the first place that the duplicated items are created at the same time and on top of they are updated exactly at the same time ?

Kpjas (talk) 12:01, 31 March 2019 (UTC)[reply]

Yes, they can be merged. After merging, check the result and delete any duplicate authors/author name strings etc. I've seen such duplicates before, presumably it's a glitch during the import. Maybe Daniel_Mietchen (the creator of both) can guess why it happened. The subsequent duplicate updates would be because they were both processed the same way by scripts. Ghouston (talk) 19:47, 31 March 2019 (UTC)[reply]

I've merged a number of such duplicates. Sometimes it's because one gets entered via DOI, the other via pubmed ID. Or sometimes they're just exact duplicates presumably due to some sort of query/database synchronization issue. ArthurPSmith (talk) 15:57, 1 April 2019 (UTC)[reply]

title (P1476) and paintings

Input appreciated at Property_talk:P1476#How_to_use_for_paintings?. Multichill (talk) 15:26, 31 March 2019 (UTC)[reply]

Deteoriorating P131

Once I had a hope that I can get all geographic object in ~~Russian~~any country by running a query "wdt:P131* wd:Q159". But now I see a trend in geographic ontology when countries cease to be administrative territorial entity (Q56061)s, city (Q515) (and similar city or town (Q7930989)) cease to be administrative territorial entity (Q56061)s. As a consequence more and more P131s become violations and should be replace with like location (P276) or located in/on physical feature (P706). Look e.g. Vladimir (Q4113022). Is it ok? --Infovarius (talk) 20:22, 31 March 2019 (UTC)[reply]

One of the previous discussions: Property talk:P131#City: ATE or not ATE --Infovarius (talk) 20:27, 1 April 2019 (UTC)[reply]

New to Wikidata, could do with some advice re merging WebP, a web image file format by Google

Hi,

While I'm not new to Wiki -- I work every so often in EN, DE and Commons -- I'm new to Wikidata, and could do with some advice.

Google has an -- unloved by some, but that is besides the point -- image format for websites called WebP, and distributes programs for converting images to and from this standard. The same program allows for both lossy and lossless conversion, and images converted to the format, both lossy and lossless, have the same file extension .webp. The touted advantage is that WebP compresses files better than the JPEG or PNG formats: file size reductions between 23% and 40-odd% are claimed.

Somehow the WebP format has ended up with three Wikidata entries: WebP Lossless Q683670, WebP Lossy Q45989100 and WebP Extended Q45989477, which seems pretty ludicrous because they are all inside the same file!

What I would propose is to

merge all three of them into one single entry
rename the entry plain WebP
put into the description lossless and lossy file format, and reference extended
put both lossy and lossless into the Statement (I looked at JPEG Q2195, it seems possible)

If anyone is interested, the whole file format is described at https://developers.google.com/speed/webp/docs/riff_container, in case there is something important I'm overlooking.

Ta very muchly!

--Peter NYC (talk) 23:53, 31 March 2019 (UTC)[reply]

I would add: all of the various Wikipedia articles seem to be sitelinked from WebP Lossless (Q683670), and are all on WebP in general, not on one of three particular subformats. - Jmabel (talk) 00:50, 1 April 2019 (UTC)[reply]
Support merge as described. No comment on WebP as a format. - PKM (talk) 01:11, 1 April 2019 (UTC)[reply]
Support Additionally, There should be a new class entity about compressed archive format in which all the instances have the property of whether it's lossy or lossless. Pebaryan (talk) 07:44, 1 April 2019 (UTC)[reply]
Oppose The three existing items WebP Lossless Q683670, WebP Lossy Q45989100 and WebP Extended Q45989477 are distinct from each other as identified at https://developers.google.com/speed/webp/docs/riff_container Each item has a different magic signature of either VP8, VP8L or VP8X and each item has a different PRONOM identifier. All three of these items are now subclasses of one I just created to fill the gap: WebP (Q62617958). I've also fixed properties and sitelinks on all four items, with WebP (Q62617958) now carrying most of the properties and all sitelinks because these properties are common to all three sub-formats WebP Lossless Q683670, WebP Lossy Q45989100 and WebP Extended Q45989477. Dhx1 (talk) 11:15, 1 April 2019 (UTC)[reply]
Oppose The only problem to me seems to be the lack of an item for all WebP files, there
⟨ lossy WepB file ⟩ subclass of (P279) ⟨ WebP file ⟩

⟨ lossy WepB file ⟩ subclass of (P279) ⟨ lossless WebP ⟩
. Who did the split and why ? I don’t understand how the « webP » item seems to have disappeared in the operation, and it seems it’s the real only problem here.
Besides, a Comment instance of (P31) seems definitely overused and definitely meaningless in the statements of JPEG. It’s a really big mess that definitely looks like the category mess in Wikipedias. I strongly Oppose this kind of messes. It probably don’t fit in any of the initial intended use of instance of (P31) in Help:BMP and seems to ignore subclass of (P279) entirely. author TomT0m / talk page 11:19, 1 April 2019 (UTC)[reply]
Comment WebP Extended Q45989477 is now split into subclasses WebP Extended Lossy Q62618601 and WebP Extended Lossless Q62618616 as each of these has a different signature and could reasonably be expected to be treated in isolation of the other sub-formats of WebP (Q62617958). For example, it may be true that software (Q7397) readable file format (P1072) WebP Lossless (Q683670), but false that software (Q7397) readable file format (P1072) WebP Extended Lossles (Q62618616). Dhx1 (talk) 11:30, 1 April 2019 (UTC)[reply]
Comment JPEG (Q2195) is now correctly instance of (P31) Wikipedia article covering multiple topics (Q21484471) covering Joint Photographic Experts Group (Q62619848) (compression algorithms/codecs based on DCT), JPEG (Q27996264) (various file formats known as "JPEG" that includes JFIF, EXIF and SPIFF), JPEG File Interchange Format (Q26329975) (JFIF file format family consisting of multiple editions) and JPEG-XT (Q28206429) (JPEG-XT extensions to the "JPEG" compression algorithm and JFIF file formats). JPEG-XL is also covered by the English Wikipedia article, but no item exists yet. None of these items are to be confused with Joint Photographic Experts Group (Q1702547) (nonprofit organisation which develops the JPEG compression algorithm, JFIF file format, various other standards). Dhx1 (talk) 13:34, 1 April 2019 (UTC)[reply]
I think it’s not necessary to come to such extremity and simply say that the main topic of the article is the JPEG file format. author TomT0m / talk page 14:49, 1 April 2019 (UTC)[reply]

has part Search is a deeply inapropriate property to state the topics of an article anyway. If it’s an article, then its parts are sections or paragraph, not topics. It’s why it’s a very bad idea in general to state that an item is about an article as topic. author TomT0m / talk page 14:52, 1 April 2019 (UTC)[reply]
Comment@TomT0m: I agree it's messy having an item about a Wikipedia article covering multiple topics. Use of has part(s) (P527) seems to be the established approach for instance of (P31) Wikipedia article covering multiple topics (Q21484471), but I do agree it is misuse of has part(s) (P527). For JPEG (Q2195) I've switched from has part(s) (P527) to a more appropriate main subject (P921). The problem is, what instance of (P31) value should be used other than Wikipedia article covering multiple topics (Q21484471)? I disagree with instance of (P31) JPEG (Q27996264) because the enwiki article also includes Joint Photographic Experts Group (Q62619848), JPEG File Interchange Format (Q26329975), JPEG-XT (Q28206429) and a few other items that don't exist in Wikidata, and doesn't mention all aspects of JPEG (Q27996264) such as Exif image file (Q26383099) and Still Picture Interchange File Format (Q26385770). Dhx1 (talk) 02:55, 2 April 2019 (UTC)[reply]
@Dhx1: It’s pretty common that a Wikipedia article covers a few secondary topics with the tendancy of people in Wikipedias to merge article on a very close topics, so if we adopt this approach and want to be consistent it could lead to a considerable amount of items to actually modify. This is not desirable for several reasons :
the regrouping may be different from one Wikipedia to another, as well as the covering of the topics (some topics may be covered as a section of an article in enwiki but may have it’s own article on frwiki — imagine frwiki in our example has an article covering both « JPEG formats and algorithm » and another covering « JPEG group ». Then … should we need an item « article covering « JPEG formats and algorithm » » distinct to item of the enwiki article covering « JPEG formats and algorithm and JPEG group » ? This is not an uncommon situation, and we’re just considering 2 wikis. Imagine all the combinations possible on all the linguistic versions … It may be manageable but not easily and may be overkill.

It breaks the assumption that items are about a real world topic that can be covered by wikipedias articles. Items are typically not about articles. There are exceptions for examples for wikinews but it’s desirable to confine them, I think, for clarity and ease of explaining to users.

Last but not least : it’s almost always possible to assign a main topic to an article, and leave aside the other closely related covered one, for example if we look at the frwiki article first sentence : « JPEG (acronyme de Joint Photographic Experts Group) est une norme » The main topic is clear, the article is about the technical standard.
author TomT0m / talk page 09:55, 2 April 2019 (UTC)[reply]

幹事長/総書記, 간사장/총비서, 秘書長/總書記, Secretary-general/general secretary

The distinction between general secretary and Secretary-general is a bit unclear and as a result they are currently being used interchangeably. Could someone with Japanese/Korean/Chinese skills have a look? Moebeus (talk) 12:54, 1 April 2019 (UTC)[reply]

ja:総書記 looks like specified for communist party (Q233591) (and that article generally mentioned Chinese Communist Party (Q17427)), while ja:幹事長 is more commonly used.

zh:總書記 is always pointing to, and only to, the political party (Q7278), while zh:秘書長 can also include government departments, NGOs, companies, and (don't laugh) yourself.

For Korean, better to ask at Wikidata:사랑방 (you may translate your questions via [3]). --Liuxinyu970226 (talk) 11:38, 2 April 2019 (UTC)[reply]

--Liuxinyu970226 (talk) 10:28, 2 April 2019 (UTC)[reply]

Properties for external MediaWiki wikis

Hi! There are a number of properties for MediaWiki wikis outside of the Wikimedia ecosystem. I just created Wikidata property linking to external MediaWiki wiki (Q62619638) for such properties to have a way to track them (I added it to many properties, but I probably missed some). Now, a discussion has come up about one that I proposed – Lokalhistoriewiki.no article ID (P6520) – because I used the article title for the URL formatter instead of the Page IDs. Now, the question doesn't just concern this ID, but rather all of these IDs. Most of them in fact use tha article titles, but some use the page IDs and some use specialized IDs (e.g. in external Wikibase instances or other MediaWiki extensions that give stable identifiers). So the question is what we should use? As far as I can see, there are two alternatives:

Use the Page IDs. A page ID for a page on a MediaWiki website can be found by appending ?action=info to the URL, and can be linked to via <wiki URL>/Special:Redirect/page/<ID>. The advantage with this is that the page ID is stable – if a page gets moved, the page ID stays the same. The disadvantages are that they are non-intuitive to find, and the links they produce are not very telling.
Use the page titles. The page names are of course very easily available to everyone, and the links produced are easy to read and usually say something about the subject of the article. The disadvantage is that these are not stable – pages can be moved, and the redirects that are created can be replaced with other pages, basically creating a form of link rot (Q1193907) here at Wikidata (and elsewhere where these properties may be used). There are ways to mend this – someone skilled enough could create a bot on Tool Labs that keeps track of page moves on these external wikis and automatically changes the values of the statements here on Wikidata when pages are moved. This will essentially be mimicking what happens when a page in any Wikimedia project is moved.

These properties are basically just sitelinks for external wikis, and hopefully one day Wikibase would be able to handle this natively. However, I'm not aware of any development on this at the moment, so at the moment these are the options I believe we have. So, what do you think is the best solution here? Page IDs or article titles? Jon Harald Søby (talk) 13:50, 1 April 2019 (UTC)[reply]

Comment I had raised similar questions in Wikidata:Property proposal/RegiowikiAT ID (Also, I had a SPARQL query there that returns similar results to Wikidata property linking to external MediaWiki wiki (Q62619638)). Jean-Fred (talk) 14:50, 1 April 2019 (UTC)[reply]

Wikidata weekly summary #358

Here's your quick overview of what has been happening around Wikidata over the last week.

Events
- Past: Wikidata meetup during the Wikimedia Summit, March 29th in Berlin (collaborative notes)
- Upcoming: Wikidata workshop for archives in Saint-Etienne, France, on April 3rd and 5th
- Upcoming: Wikidata meetup in Berlin in Wikibär on April 14th
- Upcoming: Where iNaturalist meets Wiki April 16th, in Meise (Belgium)

Other Noteworthy Stuff
- WikidataCon 2019 application, program submission and scholarship processes are now open until April 29th
- Structured Data on Commons: You can now test creating depicts statements
- While editing OpenStreetMap from the iD editor, it will now be possible to match map data with Wikidata by typing in names and getting an autocompleted label.
- OpenStreetMap is participating in this year's Google Summer of Code, and quite a few of the project ideas involve Wikidata integration.
- Discussion going on in W3C SPARQL 1.2 Community Group about the improvements in SPARQL language

Did you know?
- Newest properties:
  - General datatypes: capacity factor, position in Forsyth-Edwards Notation
  - External identifiers: Libreflix ID, Kicker.de player ID, Library of Parliament of Canada person ID, RoMEO publisher ID, Federal-State Cooperative System ID, XING company ID, L'Express person ID, Le Figaro tag ID, Le Parisien tag ID, Gamepedia article ID, FSkate.ru skater ID, Salvador Dali Museum ID, Index to American Botanical Literature ID, FaroeSoccer player ID, FaroeSoccer coach ID, Artcurial lot ID, SNISB ID, Tainacan MHN ID, 100 bombardirov person ID, Cini Foundation ID, LinkedIn personal profile ID, ACA author ID, CDEC ID, AWARE ID, JRC Names id, Zomato ID, TV Spielfilm series ID, Fandango theater ID, Stedelijk Museum Amsterdam ID, JMdictDB ID, Zagat ID
- New property proposals to review:
  - General datatypes: First attestation, match interval, réédité par, calligrapher, Ordained by, code produit, Wikidata property example for media
  - External identifiers: Baden-Württemberg Schutzgebiete-ID, K10plus editions, Utpictura18 ID, Le Vif tag ID, Common Sense Media review ID, Pro-Linux.de DBApp ID, Libregamewiki ID, Democracy Club Election ID, MARGS ID, Kobo author ID, WoRMS source ID, Kobo narrator ID, NGMDb Prod ID, Memórias da Ditadura ID, Placar UOL Eleições ID, AntWiki, MESH Concept ID, MESH Term ID, Desaparecidos Políticos ID
- Query examples:

Development
- Work on a dashboard for external identifiers (phab:T204440)
- Add baserevid to WikibaseLexeme API modules (phab:T217243)
- Add tests for embed.html (phab:T212649)
- Improve features for wikibase vandalism detection model (phab:T194737)
- Improve Property Info cache performance (phab:T218115, phab:T218197)
- Adding nofollow to external identifiers links (phab:T175230)
- Hide query helper by default in Query Service (phab:T217886)
- More work on wb_terms normalization (Phab board)
- Enable trimming whitespace around Label/Description/Aliases and Schema text (phab:T215761)
- Prevent moving Schemas between namespaces (and generally) (phab:T219313)
- Limit the length of Schema labels, descriptions, aliases, and schema text in the frontend (phab:T218867)
- Add tracking for clicks on the “check entities against this Schema” link (phab:T218899)
- Disallow importing of Schemas from another wiki or XML files to avoid ID conflicts (phab:T218181)
- Make sure RTL text is being handled correctly in the Schema labels, descriptions and aliases table (phab:T219136)
- Add a publish button on mobile termbox: (phab:T218573)
- Building the wbeditentity request to be fired on save request: (phab:T218577)

You can see all open tickets related to Wikidata here. If you want to help, you can also have a look at the tasks needing a volunteer.

Monthly Tasks
- Add labels, in your own language(s), for the new properties listed above.
- Comment on property proposals: all open proposals
- Suggested and open tasks!
- Contribute to a Showcase item.
- Help translate or proofread the interface and documentation pages, in your own language!
- Help merge identical items across Wikimedia projects.
- Help write the next summary!

Read the full report · Unsubscribe · Lea Lacroix (WMDE) 14:42, 1 April 2019 (UTC)[reply]

CIN ID

Could someone make or tell where/how to make CIN ID property for politicians in BiH? It is this website. Example for URL identificator is profil.php?profil=85, simply a number. --Obsuser (talk) 16:31, 1 April 2019 (UTC)[reply]

@Obsuser: You would need to post a "property proposal", at Wikidata:Property proposal/Authority control. Let me know if you need help with that. However, note that the site says (according to Google Translate) "more than 120 officials and politicians... by 2014, that number in the database has grown to 200. Some of the politicians from this base are no longer active or have died because of which their profiles no longer found in the database." Those numbers are low, for justifying a new property, and we need to be sure that the IDs are not reused. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:57, 1 April 2019 (UTC)[reply]

Mix'n'match scraper question

I'm a frequent user of the mix'n'match scraper, but in creating catalogs, I've only used keys and range levels. I understand what the follow levels should be used for, but haven't been able to figure out what should go where. Would anyone be able to explain, or point to an explanation? Thanks! Trivialist (talk) 18:10, 1 April 2019 (UTC)[reply]

@Trivialist: I also find this hard. Here's one I did a while back, for which I took a screenshot, so it must have been sort of working or almost working. Hopefully it helps.--99of9 (talk) 23:17, 1 April 2019 (UTC)[reply]

@99of9: Thanks! Trivialist (talk) 00:11, 2 April 2019 (UTC)[reply]

I also tried many times, succeeded exactly once, and did not take any notes of what I did ^_^" (don’t even remember which catalog it was). Thanks 99of9, that may come in handy :). Jean-Fred (talk) 08:32, 2 April 2019 (UTC)[reply]

Facto Post issue 22

It is at w:User:Charles Matthews/Facto Post/Issue 22 – 28 March 2019. Of particular interest for those involved with Wikibase is the link to a blogpost by Michael Dales, who has been contract programmer to ScienceSource (Q55439927) for the past six months, giving an outside view of the MediaWiki API aspects. Charles Matthews (talk) 09:16, 2 April 2019 (UTC)[reply]

Some discussions about disputed territories

Emergency discussion about @C933103:'s Golan Heights (Q83210) edits needed

Look here, do we know what he did here? This user simply removed country (P17)Syria (Q858) which, although I undid him, therefore and thereafter means that:

C933103 is a Judaic, that supports Israel's illegal seize of this area, and oppose any claiming from Syria government;
C933103 withdrawn NPOV and support Trumpism (Q31838499), meant that this user also agreed Trump's recognization of so-called "this is an Israel territory"
C933103 is starting an Intercontinental Edit War, just based on bad Arabic-Israel relations
C933103 is an Anti-Muslim-ism.

Do we agree his these behaviors??? --117.13.95.116 09:23, 2 April 2019 (UTC)[reply]

What? Golan Heights (Q83210) still maintain territory claimed by (P1336) by Syria (Q858) after my edits, and my edits was only a partial revert to another editors' edit a few hours ago that claimed Syria (Q858) have object of statement has role (P3831) of de jure (Q132555) on Golan Heights (Q83210) which I don't really think that's the case (at least according to my understanding which have a chance of not aligned to fact), and thus I have raised the question to the editor that committed the previous edit on the talk page while making a revert on the edit. C933103 (talk) 09:36, 2 April 2019 (UTC)[reply]

Wrong, after Your edits, the P17 Syria value was unfairly lost temporary. --2409:8902:9300:2967:8520:E396:FDC6:D58D 09:43, 2 April 2019 (UTC)[reply]

It looks like that we have troubles about ethnic conflicts here, so helps from administrators that can speak Arabic and Hebrew languages needed: @علاء, باسم, Deror_avi, יונה_בנדלאק:. --Liuxinyu970226 (talk) 10:13, 2 April 2019 (UTC)[reply]

This verion looked correct. maybe lebanon need to be removed from the territory claimed by (P1336). they have a claim about very small part of the golan (Shebaa farms (Q1133272) only). so it probably better to put the claim in Q1133272 and not on the Q83210. - yona b (talk) 10:50, 2 April 2019 (UTC)[reply]

i agree to what @יונה בנדלאק: saysباسم (talk) 11:10, 2 April 2019 (UTC)[reply]

lebanon need to be removed from the territory claimed by (P1336). they have a claim to (Shebaa farms (Q1133272) which is not a part of the Golan. Deror avi (talk) 19:51, 2 April 2019 (UTC)[reply]

IIRC that is again a bit like the Kashmir situation below, where one side claim a place is part of the larger region while the other side doesn't recognize such position. C933103 (talk) 03:23, 3 April 2019 (UTC)[reply]

@C933103: I'm just wondering why this area is like Kashmir, is PR China also claiming Golan? --Liuxinyu970226 (talk) 03:48, 3 April 2019 (UTC)[reply]

Because IIRC Lebanon (Q822) think Shebaa farms (Q1133272) is not part of Golan Heights (Q83210) but Israel (Q801) think it is? Not sure about UN/Syria's position. C933103 (talk) 04:51, 3 April 2019 (UTC)[reply]

No, the Israel government also don't think this farm is a part of Golan, both are different disputed areas. --60.26.9.220 08:34, 3 April 2019 (UTC)[reply]

While figuring out how to deal with the subject of the Golan Heights is important, I think it's quite clear that the OP/IP should be immediately permanently banned, unless the content of the post was somehow a result of some serious mistranslation. --Yair rand (talk) 05:41, 3 April 2019 (UTC)[reply]

Sure, I rolled back to the normal status of Golan Heights (Q83210), so that Syria is shown normally. --60.26.9.220 08:34, 3 April 2019 (UTC)[reply]

The user who started the discussion seems to be using dynamic IP that I don't think banning can make any difference. C933103 (talk) 13:21, 3 April 2019 (UTC)[reply]

de jure (Q132555)?

Someone keeping adding de jure (Q132555) back to the page as Syria's role on the territory but they continually refusing to provide any source for it. Actually, what is the applicability of this role when it come to a conflicted territory? According to which law was Syria (Q858) having de jure (Q132555) role on Golan Heights (Q83210)? C933103 (talk) 03:37, 3 April 2019 (UTC)[reply]

Yes, please read their constitution: s:ar:دستور سوريا. --60.26.9.220 08:38, 3 April 2019 (UTC)[reply]

Going by this logic, Israel would also have de jure sovereignty on Gaza strip or West Bank, China would also have de jure sovereignty on Taiwan and vice versa Taiwan would also have de jure sovereignty on China. I am not going to say whether it is a right thing to do or not to add the "de jure" role to all these countries involved in conflicts, but I want other wikidata users participating in the discussion consider what is the right time for the "de jure" role to be applied onto countries and with these examples listed out in mind. C933103 (talk) 13:18, 3 April 2019 (UTC)[reply]

Kashmir (Q43100)

@Liuxinyu970226: In your recent edits to the Kashmir (Q43100) page, you added China as a country that own Kashmir and also an English description saying that "former princely state, now a conflict territory between India and Pakistan (and in rarely seen cases, the People's Republic of China". However there are a few problems with the edit.

The official position of China is that they don't recognize the part they control as part of the region of Kashmir, given the view point should China still be added as a P17 to the Kashmir region?
I don't think China claim any part of the area that were actually part of the former princely state that the new description seem to imply?

C933103 (talk) 09:47, 2 April 2019 (UTC)[reply]

"now administered by three countries: India, Pakistan, and China." is wrong in your opinion? --Liuxinyu970226 (talk) 10:10, 2 April 2019 (UTC)[reply]

Read the entire sentence.... C933103 (talk) 10:30, 2 April 2019 (UTC)[reply]

@C933103: "The official position of China is that they don't recognize the part they control as part of the region of Kashmir" so that Kashmir is not a PR China territory? So there's no problem about China at all? --Liuxinyu970226 (talk) 10:37, 2 April 2019 (UTC)[reply]

The best area to discuss your second point, TBH, is Talk:Q230830, you should talk this problem here by creating it. --Liuxinyu970226 (talk) 10:37, 2 April 2019 (UTC)[reply]

That is why you would never hear Chinese media say something along the line of "Chinese controlled part of Kashmir". But then the problem is that India see those Chinese-controlled area as part of Kashmir. The situation is actually a bit similar to the Southern Kuril Islands where Japan doesn't recognize those islands as part of Kuril Islands instead they see them as islands associated to the Hokkaido.C933103 (talk) 11:27, 2 April 2019 (UTC)[reply]

@Liuxinyu970226, C933103: This seems like the lack of informations about Aksai Chin (Q230830), hence I re-introduced India on P17 of that item, and added both PRC and India as P1336, that said, for such disputed territories that controlled areas on both sides are not fully, we need P17 values same as P1336. --60.26.9.220 01:02, 3 April 2019 (UTC)[reply]

Thx. --Liuxinyu970226 (talk) 04:10, 3 April 2019 (UTC)[reply]

[Breaking change] Empty containers in JSON outputs will be serialized as empty object "{}"

Hello all,

This change is relevant for everyone using APIs, JSON output and dumps in their tools or gadgets.

Currently, when an object is empty (for example descriptions and aliases), it is rendered as an empty array [] in JSON. (Example) We want to serialized it as an empty object {} instead. This change will ease the deserialization process and bring more consistency in our code as some other places already use JSON objects instead of arrays.

The impact of this change will be in JSON outputs (Special:EntityData) and JSON dumps, as well as the output of wbgetentities, wbgetclaims and editing APIs.

If you’re maintaining tools that use Special:EntityData, you may want to check your code to make sure that it reflects this change, e.g. items with no labels, descriptions, aliases or sitelinks are properly deserialized by your tool.

You can already test your code against our test system on beta.wikidata.org, for example on this item. According to our stable interface policy, the change will be enabled four weeks after this announcement, on April 30th.

In the meantime, if you have any issue or question, feel free to leave a comment in this ticket.

Thanks for your attention, Lea Lacroix (WMDE) (talk) 10:21, 2 April 2019 (UTC)[reply]

@Lea Lacroix (WMDE): I don't think that this can be a breaking change, maybe just say "import change" is enough? --Liuxinyu970226 (talk) 10:24, 2 April 2019 (UTC)[reply]

It's a change that could easily break something, so the wording seems appropriate. Ghouston (talk) 10:49, 2 April 2019 (UTC)[reply]

According to the definition of the stable interface policy, a breaking change is "a change to an API or data format that violates guarantees given or widely assumed before". In that case, the impact is mostly for people reusing Wikidata's data on their tool, still it is a change on something that was assumed otherwise. Lea Lacroix (WMDE) (talk) 11:01, 2 April 2019 (UTC)[reply]

that's very counter-intuitive. Data type is not something that depends on object state (empty or not empty). I've never seen rule like "if array is empty, serialize it as empty object, rather than an empty array" before. Not sure how exactly it shall be handled in strong type based language tools and libraries (such as Jackson for Java). Do developers have any examples or advises? Would be much better just to omit value completely (do not output empty object/array at all). -- Vlsergey (talk) 11:32, 2 April 2019 (UTC)[reply]

@Vlsergey: Nonempty labels, descriptions, aliases, or claims are already serialized as objects (e. g. { "en": { "language": "en", "value": "Douglas Adams" } } or { "P31": [ … ], "P18": [ … ] }). The fact that those objects turned into arrays when empty was a bug, which we’re now fixing. --Lucas Werkmeister (WMDE) (talk) 12:43, 2 April 2019 (UTC)[reply]

Ohh, seems i misunderstood the change. If all objects will be objects, and arrays stay arrays (whatever content is), that's good. -- VlSergey ^(трёп) 13:17, 2 April 2019 (UTC)[reply]

@Lea Lacroix (WMDE): according to the policy you're supposed to notify the Pywikibot list. I don't see an email yet. Did you forget to do this or is it stuck somewhere in moderation? For the pywikibot part I created Phab:T219891. Multichill (talk) 16:06, 2 April 2019 (UTC)[reply]

Hello @Multichill: I sent the email yesterday in the same time as the others, so I guess it's still in moderation. Lea Lacroix (WMDE) (talk) 08:04, 3 April 2019 (UTC)[reply]

This is a great move! If we are to change dump format, then I humbly suggest the addition of revision ids to the entities dumped. I think this would make it easier for data consumers to evaluate freshness and keep data in sync after importing a dump. See the corresponding patch. − Pintoch (talk) 12:43, 3 April 2019 (UTC)[reply]

Question about property

We have this property said to be the same as (P460) wich is in the description stated to be "this item is said to be the same as that item, but the statement is disputed" do we have a property for this is exactly equal to I ask because I do some work on military ranks and they have diiferent names in Army, Navy and Airforce but they are on the same rank level and have roughly the same command responsibilities/ duties Andber08 (talk) 11:20, 2 April 2019 (UTC)[reply]

how about exact match (P2888)? MSGJ (talk) 14:13, 2 April 2019 (UTC)[reply]

The exact match (P2888)? only allows URLs and as far I understand its not ment to be used internaly on WikidataAndber08 (talk) 16:00, 2 April 2019 (UTC)[reply]

@Andber08, MSGJ: No, exact match (P2888) is for linking to external URL's that are the same conceptually. Within Wikidata, if two things are really identical they should be merged into one item. However, the presence of sitelinks may prevent a merge, so we have the permanent duplicated item (P2959) property to handle those cases. In this case however, said to be the same as (P460) is exactly the right property to use - from some perspectives these ranks are the same, but they do have distinct labels and other distinctions like military branch. ArthurPSmith (talk) 16:03, 2 April 2019 (UTC)[reply]

"Having roughly the same responsibilities" is not the same thing as "being the same thing". --Yair rand (talk) 23:16, 2 April 2019 (UTC)[reply]

Usuario discusión:Pepa.charro

Hola, Soy Pepa Charro y he escrito en varias ocasiones para eliminar la fecha de nacimiento del perfil que han creado sobre mi persona. NO ES MI FECHA DE NACIMIENTO

Done, eliminado--Ymblanter (talk) 20:07, 2 April 2019 (UTC)[reply]

Change a property datatype

Is it possible to change a property datatype post-creation?

Currently Irish Grid Reference (P4091) is set to the external identifier datatype. However, this should really be string as it's just a coordinate value (the Irish equivalent of OS grid reference (P613)).

I've already removed Wikidata property for authority control for places (Q19829908) from the property --SilentSpike (talk) 15:48, 2 April 2019 (UTC)[reply]

the way to go is by replacing the property with entirely new one through Wikidata:Property proposal. Circeus (talk) 20:55, 2 April 2019 (UTC)[reply]

It may be possible for the developers to fix a case like this, where the value is not changing, just the datatype. Try the Contact the development team page... ArthurPSmith (talk) 20:59, 2 April 2019 (UTC)[reply]

Help with Hebrew needed

It looks like the NNL IDs associated with Orientalism (Q1574967) are for Hebrew translations of this work. Can someone fluent in Hebrew make sure these values are on the correct item(s)? Thanks. (I've separated the English first hardcover and paperback editions from the work item.) - PKM (talk) 22:17, 2 April 2019 (UTC)[reply]

Google+

Anything Google+ is now in essence dead, and Google+ ID (archived) (P2847) could be deleted wholesale. I'd like to remove the Google+ ID from the self-proclaimed G+ murderess Emma Blackery (Q15994935).^[4] What's the plan? –84.46.52.197 00:12, 3 April 2019 (UTC)[reply]

Google+ pages are full of useful information, and the internet archive has done extensive archiving of the public pages. I recommend against removing the IDs. --Yair rand (talk) 01:40, 3 April 2019 (UTC)[reply]

I'm also strongly against the removal of Google+ ID (archived) (P2847): we don't delete items about people when they die... -- Brasig (talk) 06:26, 3 April 2019 (UTC)[reply]

Enterprise pages are still functioning C933103 (talk) 04:44, 3 April 2019 (UTC)[reply]

Why would we delete the property just because the resource is down? Is it not worth archiving? —Justin (koavf)❤T☮C☺M☯ 06:52, 3 April 2019 (UTC)[reply]

URL shortener for the Wikimedia projects will be available on April 11th

Hello all,

Having a service providing short links exclusively for the Wikimedia projects is a community request that came up regularly on Phabricator or in community discussions.

After a common work of developers from the Wikimedia Foundation and Wikimedia Germany, we are now able to provide such a feature, it will be enabled on April 11th on Meta.

What is the URL Shortener doing?

The Wikimedia URL Shortener is a feature that allows you to create short URLs for any page on projects hosted by the Wikimedia Foundation, in order to reuse them elsewhere, for example on social networks or on wikis.

The feature can be accessed from Meta wiki on the special page m:Special:URLShortener (will be enabled on April 11th). On this page, you will be able to enter any web address from a service hosted by the Wikimedia Foundation, to generate a short URL, and to copy it and reuse it anywhere.

The format of the URL is w.wiki/ followed by a string of letters and numbers. You can already test an example: w.wiki/3 redirects to wikimedia.org.

What are the limitations and security measures?

In order to assure the security of the links, and to avoid shortlinks pointing to external or dangerous websites, the URL shortener is restricted to services hosted by the Wikimedia Foundation. This includes for example: all Wikimedia projects, Meta, Mediawiki, the Wikidata Query Service, Phabricator. (see the full list here)

In order to avoid abuse of the tool, there is a rate limit: logged-in users can create up to 50 links every 2 minutes, and the IPs are limited to 10 creations per 2 minutes.

Where will this feature be available?

In order to enforce the rate limit described above, the page Special:URLShortener will only be enabled on Meta. You can of course create links or redirects to this page from your home wiki.

The next step we’re working on is to integrate the feature directly in the interface of the Wikidata Query Service, where bit.ly is currently used to generate short links for the results of the queries. For now, you will have to copy and paste the link of your query in the Meta page.

Documentation and requests

If you have any question or requests, feel free to leave a comment under this Phabricator task
The user documentation is available here: please help us to translate it in your language!
See also the technical documentation of the extension

Thanks a lot to all the developers and volunteers who helped moving forward with this feature, and making it available today for everyone in the Wikimedia projects! Lea Lacroix (WMDE) (talk) 11:44, 3 April 2019 (UTC)[reply]

That's great news! Thank you, Lea, for bring it to our attention. I have taken the liberty of copying much of your post to Wikidata:URLShortener, so that we can use it as the basis of Wikidata-specific documentation. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:03, 3 April 2019 (UTC)[reply]

Also, please see Wikidata:Property proposal/WMF short URL. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:46, 3 April 2019 (UTC)[reply]

Honorary doctorates

I recently noticed honorary doctorate from the McGill University (Q62061080) being added to items on my watchlist. While I'm sure that was done in good faith, it strikes me as the wrong way to model the data. What do others think? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:58, 3 April 2019 (UTC)[reply]

@@ Line 589: / Line 589: @@
 ORDER BY ?year str(?old_workLabel) str(?old_work) ?new_year str(?new_workLabel)
 }} [[User:Jheald|Jheald]] ([[User talk:Jheald|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 09:18, 29 March 2019 (UTC)  @[[User:Moebeus|Moebeus]], [[User:Jheald|Jheald]]: Thank you a lot for your answers. The work around to get the translations of a work seems to be not satisfying enough, as it does not easily answer questions as: "give me a list of most translated works" or "sort the languages based on translation counts of certain work (e.g. book)". I think it makes sense to judge the translation movement of important works with a direct subject -> property -> object format. I'll suggest it to be created and hope it will be accepted.
-BTW: I would suggest the name "Translated to" (=language) to avoid ambiguity with existing properties. Would be glad for initial feedback! [[User:Sky xe|Sky xe]] ([[User talk:Sky xe|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 15:27, 3 April 2019 (UTC)
+BTW: I would suggest the name "Translated to" (=language) to avoid ambiguity with existing properties. Would be glad and thankful for initial feedback! [[User:Sky xe|Sky xe]] ([[User talk:Sky xe|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 15:27, 3 April 2019 (UTC)
 == Do you know about [[Wikidata:Editing restrictions]]? ==

Wikidata:Project chat: Difference between revisions

Revision as of 15:32, 3 April 2019

Popular classifieds website Friday-Ad

Scientific names of taxa should be a separate entities from the taxa themselves

Here are some thoughts...

Use cases

Ways forward?

Two properties pointing to the name

Possible solution

Types

Sitelinks

External IDs

Previous discussion

Comment

Failure of logical types

Owl on Main Page

Sub-headings

Request for protect:Q179294

East Jerusalem

Incorrect Wikisource links

Q925929 Leroy P. Steele Prize

items for box-header and box-footer portal subpages

How to deal with incorrect data on external identifiers?

Q321014 error

Help on operating system constraint

Hill and mountain class structure

Relation between the two

Telegram bot

P463 (member of) and Q1439921 (list of regicides of King Charles I)

Severe problems editing Wikidata

Sitelinks to Wiktionary

State of the art of the commons category problem

A lot of partners

Any efforts on making some more advanced query-generator for wikidata?

Data model intent on ranking and Wikidata documentation on it contradiction

How long does a P1630 (formatter URL) change take to propagate?

Awards not accepted

Translation property

Do you know about Wikidata:Editing restrictions?

Second line and language box

New accounts and QuickStatements

Inferring notability from external-id properties

Listeria and long pages

Porn link in Q3070476

Predicato onomastico vs Particella nobiliare - should they be merged?

Merging duplicated scientific articles

title (P1476) and paintings

Deteoriorating P131

New to Wikidata, could do with some advice re merging WebP, a web image file format by Google

幹事長/総書記, 간사장/총비서, 秘書長/總書記, Secretary-general/general secretary

Properties for external MediaWiki wikis

Wikidata weekly summary #358

CIN ID

Mix'n'match scraper question

Facto Post issue 22

Some discussions about disputed territories

Emergency discussion about @C933103:'s Golan Heights (Q83210) edits needed

de jure (Q132555)?

Kashmir (Q43100)

[Breaking change] Empty containers in JSON outputs will be serialized as empty object "{}"

Question about property

Usuario discusión:Pepa.charro

Change a property datatype

Help with Hebrew needed

Google+

URL shortener for the Wikimedia projects will be available on April 11th

Honorary doctorates

Navigation menu

Search