Wikidata:Project chat: Difference between revisions

Content deleted Content added

Inline

Revision as of 14:04, 5 September 2018

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

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/10.

Inconsistent constraints for father (P22) and mother (P25)

[Copying the message from WikiProject Ontology because I'm not sure it's the best place for discussing that.

I'm currently working on anomalies listed in Wikidata:Database reports/Constraint violations/P25.

For Nijinsky (Q26798) and other instances of racehorse (Q10855242), the property mother (P25) is flagged as an error because racehorse (Q10855242) is not a subclass of any allowed class for subject of this property. Among allowed classes is listed eukaryote (Q19088), which in fact is an instance of taxon (Q16521). I've hard time to figure where this is breaking, and I don't want to meddle in the metaclasses structure.

The problem does not occur with father (P22), which is allowed for animal (Q729), of which racehorse (Q10855242) is a subclass. Maybe the solution is to align the constraints of mother (P25) on those of father (P22)?

In fact, eukaryote (Q19088) seems a weird class to allow mother (P25). Fungi and Protozoa are eukaryots, but don't have father and mother, AFAIK. So, the choice of replacing it by animal (Q729) like in father (P22) seems reasonable to me. Which does not solve the metaclass mess around eukaryote (Q19088), but I'll let that point for ontology gurus to settle. I'll do it if there is consensus. – The preceding unsigned comment was added by Bvatant (talk • contribs) at 13:12, 19 August 2018‎ (UTC).[reply]

@Bvatant: This is another manifestation of the issue discussed recently - but not yet resolved - at Wikidata:Project chat/Archive/2018/08#What heart rate does your name have?. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:39, 19 August 2018 (UTC)[reply]

@Pigsonthewing: Indeed. Meanwhile, waiting for clarification on taxons, do you agree with my proposal of using animal (Q729) instead of eukaryote (Q19088) for mother (P25) type constraint, as it is for father (P22)? Bvatant (talk) 20:36, 19 August 2018 (UTC)[reply]

Instances (aka individuals) of racehorse (Q10855242) have nothing to do with taxa. --Succu (talk) 20:34, 20 August 2018 (UTC)[reply]

BTW: stallion (Q757833) and man (Q8441) do have in common male organism (Q44148) and belonging to the class (Q37517) mammal (Q7377). Why do we differ between male organism (Q44148) and male (Q6581097) at all? --Succu (talk) 21:11, 20 August 2018 (UTC)[reply]

@Succu: Because from lingustisc view is it problematic. When you says about man that is male organism (Q44148) in czech language, is it considered as near vulgar (he is very sexual active). And the same situation is in many other languages. JAn Dudík (talk) 20:10, 28 August 2018 (UTC)[reply]

Hey JAn Dudík, of course there are cultural differenties. Seems like my username has a connotation at viwiki. ;) But from the biological POV there is no difference. This reminds me to 1860 Oxford evolution debate (Q165720). Regards --Succu (talk) 20:27, 28 August 2018 (UTC)[reply]

So, we agree the current state of affairs is a mess. What do you suggest for e.g., Giant panda (Q33602)? It's rather weird to add it back in an ad hoc way to the property constraints, as it were. @Pigsonthewing: @Succu: Bvatant (talk) 16:59, 24 August 2018 (UTC)[reply]
- It seems logical that Succu's argument "Instances (aka individuals) of racehorse (Q10855242) have nothing to do with taxa" can be reduced to "individual horse (Q726) have nothing to do with Equus ferus caballus (Q26644764)" or "Tim Berners-Lee (Q80) has nothing to do with Homo sapiens sapiens (Q3238275)". I don't think any reasonable observer would agree with that. Until that issue is resolved, we won't be able to move forward with the above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:26, 24 August 2018 (UTC)[reply]
  - Breeds are not taxa. --Succu (talk) 20:53, 24 August 2018 (UTC)[reply]
  - Off-topic: Andy Mabbett, thanks for pointing it out: human (Q5) was connected to Homo sapiens sapiens (Q3238275), but horse (Q726) wasn't connected to Equus ferus caballus (Q26644764). Fixed now :-) --andrybak (talk) 13:52, 29 August 2018 (UTC)[reply]

I would propose limiting the scope of father (P22) and mother (P25) to mammal (Q7377). The mechanistic definition of biological parent which applies to humans only goes as far as mammals. Even though most other animals have biological sex, the mechanism of gender determination isn't the same as that in humans and the labels "male" and "female" are assigned by partial similarity with human biology. For example drone (Q650665) (traditionally considered "male") only have one parent (traditionally considered "mother"). Hippocampus (Q74363) "males" get pregnant. Since the human definition of "mother" and "father" doesn't fit these other animals, we shouldn't use the same property. Deryck Chan (talk) 22:42, 30 August 2018 (UTC)[reply]

I'm not sure the constraint route is the right way to go. Irrespective of how "female/male" is defined or determined in a species, it is often defined for non-mammals. Our definition of mother is "female parent", which apparently still stands in the examples you gave. But it may be worth opening up another option: for asexual reproducers or those without a male/female definition, it would probably help to have a non-sexed Property:Biological_parent, of which mother and father could be supproperties. --99of9 (talk) 00:13, 31 August 2018 (UTC)[reply]

Denisova 11

Is Denisova 11 (Q56233289) to be treated as humanoid (Q502931)? --Succu (talk) 21:30, 22 August 2018 (UTC)[reply]

As you know, I just created that, Yet you have not pinged me here. Why is that? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:33, 22 August 2018 (UTC)[reply]

Oh, I pinged you. So why? --Succu (talk) 21:38, 22 August 2018 (UTC)[reply]

„Here we present the genome of ‘Denisova 11’, a bone fragment” --Succu (talk) 21:59, 22 August 2018 (UTC)[reply]

Are not those folks simply archaic human (Q284851)?Bvatant (talk) 21:55, 22 August 2018 (UTC)[reply]

So how this item could be remodeled, Bvatant? --Succu (talk) 22:08, 22 August 2018 (UTC)[reply]

archaic human (Q284851): A subclass of human evolution (Q83944)?!? Has part Homo heidelbergensis (Q105784)?!? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:27, 22 August 2018 (UTC)[reply]

Succu Andy Mabbett Indeed I don't know, because we stumble here on the fact that archaic human (Q284851) is a subclass of human evolution (Q83944), has part(s)(?) elements such as Neanderthal (Q40171), itself instance of taxon (Q16521). I can't make sense for the moment of such a mess. The way taxons conflate with classes in WD is just a mystery for me, I'm currently trying to make sense of it and clarify constraints on parenthood relations mother (P25) father (P22) child (P40), in order to enable race horses, giant pandas and other pets to have proper genealogy, along with deities, dragons etc. I'm pretty sure that if Denisova 11 (Q56233289) is declared as type archaic human (Q284851), she will not be allowed by the current constraints to have a father and mother like you and me, more than she is with her current types: neither humanoid (Q502931) nor hybrid (Q42621) are allowed to bear mother (P25) or father (P22) in the current state of affairs. Will think about it, but a quick and dirty way to shunt the taxonomic jungle would be to declare those folks as instance of person (Q215627), which would be more respectful to them than humanoid (Q502931) or hybrid (Q42621). But just my 0.02€ :-) Bvatant (talk) 22:51, 22 August 2018 (UTC)[reply]

I think archaic human (Q284851) are all the members of Homo (Q171283) (Human) which aren't anatomically modern human (Q5891007). Taxons vs subclasses are a bit of a mystery. I thought Wikidata items needed to be a subclass of something if they could have instances. E.g.,

⟨ Wolf of Gysinge (Q6516548)  

 ⟩ instance of (P31) ⟨ wolf (Q18498)  

 ⟩

requires that wolf (Q18498) be a subclass of something, presumably Canis (Q149892). But I only get reverted if I do that, most recently with "it's already a subclass". Ghouston (talk) 03:27, 23 August 2018 (UTC)[reply]

We could use instance of Q171283; notwithstanding that that is but an instance-of-an-instance-of second-order class (Q24017414). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:42, 23 August 2018 (UTC)[reply]

Any comments to this solution? --Succu (talk) 18:41, 24 August 2018 (UTC)[reply]

@Succu: Now I'm a bit lost, sorry. Which problem does this change solve? We have two different problems here, #1 consensus on the type(s) of Denisova 11 (Q56233289) and #2 allow at least one of those types to bear mother (P25) and father (P22). Do you mean your proposal solve both, supposing the type archaic human (Q284851) is added to Denisova 11 (Q56233289)? I don't want to nitpick, again, but those things are really tricky. In any case, seems to me your solution conflates the person/organism who was alive here and there, and its fossil remnant. A fossil does not have mother and father, for example. See my other comment below.Bvatant (talk) 20:50, 24 August 2018 (UTC)[reply]

I responded to this remark. --Succu (talk) 21:02, 24 August 2018 (UTC)[reply]

I'd like to discuss Denisova 11 (Q56233289) nothing else. I don't think the current English description (girl with a Neanderthal mother and a Denisovan father) is correct. „Denisova 11“ is the name of a bone fragment. I created minimalistic items for earlier findings: Denisova 3 (Q56240560), Denisova 4 (Q56240584), Denisova 5 (Q56240616) and Denisova 8 (Q56240592). I doubt the usage of place of burial (P119) and related properties is correct. All fragments were found at Denisova Cave (Q1029322). I can not find any evidence that the girl - which the bone fragment was part of - was buried there. I don't think the usage of hybrid (Q42621) for a human is correct. --Succu (talk) 19:56, 23 August 2018 (UTC)[reply]

Succu +1 ! I pretty much like your minimalist descriptions, as they elegantly kick off the taxonomic issue. And indeed, those entities are fragmentary fossils, not persons (whatever their classification).Bvatant (talk) 20:45, 23 August 2018 (UTC)[reply]

You appear to be labouring under a misapprehension. The item is about the humanoid, not the bone. If you wish to create an item about the bone, no-one is stopping you. Readers will also note that P119 has many aliases, not all of which imply burial per se; and that "Hybrid" is exactly the term used by one of the cited sources - in its title no less. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:20, 23 August 2018 (UTC)[reply]

Further: "The tiny arm or leg fragment belonged to Denisova 11, a 13-year-old hybrid hominin" - [1]. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:33, 23 August 2018 (UTC)[reply]

Your latest argument, Andy Mabbett, led me to read through en:Denisovan#Fossils and indeed "Denisova 2 and Denisova 3 are prepubescent or adolescent females, while Denisova 4 and Denisova 8 are adult males". If I get correctly the meaning of are in this sentence, the names "Denisova n" denote individual persons, and not their fossil remains. So much for your interpretation, Succu, even if I was tempted to buy it yesterday. I would be tempted to extend parenthood properties used on human (Q5) to the whole genus Homo (Q171283). But what is the best way to do that? – The preceding unsigned comment was added by Bvatant (talk • contribs) at 16:47, 24 August 2018‎ (UTC).[reply]

„Denisova n“ refers to the label given to the specimen. See e.g. „Scientists exploring Denisova Cave in the Altai Mountains discovered the worn baby tooth in 1984 and labeled it ‘Denisova 2.’“. --Succu (talk) 18:32, 24 August 2018 (UTC)[reply]

@Succu:Sorry for nitpicking :-) ... the source you quote is not convincing at all. First it's not a primary research paper, but an article in general press, less precise on vocabulary in general, and the referent of "it" in "labeled it" can be either the tooth or the baby. Regarding Denisova 11, this article at Smithsonian's is clearly using the name several times as the name of the girl, not of her bone, e.g., Denisova 11’s mother was more closely related to Neanderthals dwelling in western Europe than those residing in the Siberian cave some 120,000 years ago. Denisova’s paternal relatives, on the other hand, stuck to the region surrounding the cave—Denisova 3, the hominin whose pinky toe first led scientists to the species, lived in the area a few thousand years after Denisova 11.Bvatant (talk) 19:29, 24 August 2018 (UTC)[reply]

Why are people assuming there is no ambiguity here and that those who use it one way or the other are simply wrong? - Jmabel (talk) 19:33, 24 August 2018 (UTC)[reply]

Please see above, where I wrote "The item is about the humanoid, not the bone. If you wish to create an item about the bone, no-one is stopping you.". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:16, 24 August 2018 (UTC)[reply]

So this is item not about a member of Hominidae (Q635162), but only the reseamblace (humanoid) with a „human“ (=Q5?) --Succu (talk)

I presume Andy meant to write "hominid" rather than "humanoid". And I suspect you are trying to pick a fight rather than to reach consensus. - Jmabel (talk) 02:58, 25 August 2018 (UTC)[reply]

Did he? He referenced humanoid (Q502931) [2], [3]. --Succu (talk) 20:57, 25 August 2018 (UTC)[reply]

From the original publication (first sentence of the abstract): „Neanderthals and Denisovans are extinct groups of hominins that separated from each other more than 390,000 years ago.“. What consensus do you have in mind, Jmabel? --Succu (talk) 20:23, 27 August 2018 (UTC)[reply]

The one most of the people here seem to be trying to work toward, rather than see how close to their own original view we can end up. - Jmabel (talk) 22:28, 27 August 2018 (UTC)[reply]

From en:Hominid (disambiguation): „A hominid is any primate in the family Hominidae“. From en:Humanoid: „is something that has an appearance resembling a human without actually being one“. From your point of view: are these references well done? --Succu (talk) 20:47, 28 August 2018 (UTC)[reply]

To cite from a publication I referenced today multiple times Genera of the human lineage (Q28177674): „What Is a Hominid?“ They are not wondering about to be humanoid (Q502931), Mr. Pigsonthewing. --Succu (talk) 20:00, 1 September 2018 (UTC)[reply]

Try Nuclear and mitochondrial DNA sequences from two Denisovan individuals (Q29013840). Of course these fragments belog to a particular individual, but they are not same as these individuals. --Succu (talk) 20:35, 24 August 2018 (UTC)[reply]

@Jmabel:. Yes there is ambiguity, that's why we are discussing :-). For the sake of Wikidata consistency (at least local consistency) we must come to a consensus, or agree the name is ambiguous and create two elements, one for the person, and one for the fossil.Bvatant (talk) 20:52, 24 August 2018 (UTC)[reply]

Only the secondary sources (you added) use the term „hybrid“ not the primary source: The genome of the offspring of a Neanderthal mother and a Denisovan father (Q56234568). --Succu (talk) 20:09, 27 August 2018 (UTC)[reply]

Neanderthal (Q40171) == Extinct species of the genus Homo"; Denisova hominin (Q151055) == "Paleolithic-era species of the genus Homo"; ;hybrid (Q42621) == "offspring of cross-species reproduction". Though why the former two items are not marked up as having, for instance, parent taxa, is left as an exercise for the reader. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:58, 28 August 2018 (UTC)[reply]

Could you please explain this cryptic answer. Thanks in advance. --Succu (talk) 21:00, 28 August 2018 (UTC)[reply]

wikt:exercise for the reader. But never mind, I found out why Q151055 has no parent taxon Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:13, 28 August 2018 (UTC)[reply]

Oh, it would be very interesting to have scientific reference for the treatment of Denisova hominin (Q151055) as a species (Q7432). --Succu (talk) 21:06, 28 August 2018 (UTC)[reply]

Perhaps you could ask an editor who labelled it as such. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:13, 28 August 2018 (UTC)[reply]

That's the way you argue: Version vom 11. März 2014, an early Bot expierence?

BTW The evolution of Homo sapiens denisova and Homo sapiens neanderthalensis miRNA targeting genes in the prenatal and postnatal brain (Q28603765) is a source which treated Denisova hominin (Q151055) as subspecies (Q68947)... --Succu (talk) 21:29, 28 August 2018 (UTC)[reply]

If this item is about the girl then why this item is not an instance of human (Q5)? --Succu (talk) 21:14, 24 August 2018 (UTC)[reply]

The description of Q5 is "common name of Homo sapiens (Q15978631), unique extant species of the genus Homo" (though I shall now remove the QID from that)). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:18, 24 August 2018 (UTC)[reply]

I think the usage of female (Q6581072) implies human (Q5). You added the references. --Succu (talk) 21:26, 24 August 2018 (UTC)[reply]

I would gladly extend the definition of Q5 to include the whole genus Homo.Bvatant (talk) 21:36, 24 August 2018 (UTC)[reply]

I don't think that's OK. Please see population (Q15840798). --Succu (talk) 21:29, 25 August 2018 (UTC)[reply]

That is a subclass of population (Q2625603) (which you added on 25 August) and of Homo (Q171283) (which you added on 26 August). Aside from that issue; what is its relevance here? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:20, 1 September 2018 (UTC)[reply]

I'm aware of what I added to population (Q15840798), and I think you are aware about what I meant above. --Succu (talk) 20:08, 1 September 2018 (UTC)[reply]

My question - which you have not answered - was "what is its relevance here?". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:25, 1 September 2018 (UTC)[reply]

„relevance“ of what. Please don't be vague. Thx. --Succu (talk) 21:13, 1 September 2018 (UTC)[reply]

I removed two wrong references to The genome of the offspring of a Neanderthal mother and a Denisovan father (Q56234568). --Succu (talk) 20:14, 1 September 2018 (UTC)[reply]

Promptly reverted of course... --Succu (talk) 20:20, 1 September 2018 (UTC)[reply]

[ec] I've restored the source. I note that Succu gives no indication of why they believe it to be "wrong". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:25, 1 September 2018 (UTC)[reply]

What about a full text search? --Succu (talk) 20:30, 1 September 2018 (UTC)[reply]

Maybe you find this change more „entertaining“. --Succu (talk) 20:52, 1 September 2018 (UTC)[reply]

entertaining. Not for me! --Succu (talk) 21:01, 1 September 2018 (UTC)[reply]

Is there any reason why this girl should not be treated as an instance of Denisova hominin (Q151055)? --Succu (talk) 05:48, 2 September 2018 (UTC)[reply]

Yes: The subject is "...a hybrid between Neanderthals and Denisovans.", as quoted from one of the cited sources; had a "Neanderthal mother" according to a second cited, and quoted, source; and was "...the offspring of a Neanderthal mother and a Denisovan father" according to the quoted title of a further cited source, which you yourself created as an item - which is why the reason I gave in the edit summary for the diff you provide was "per cited & quoted sources". Conversely, your claim that she was a straightforward "instance of Denisova hominin" was uncited. Your repeated, and unexplained, attempts to make this item about anything other than what it actually is about are becoming tendentious. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:15, 2 September 2018 (UTC)[reply]

So if you insist on the exact wording of your secondary sources: I can not find the word humanoid (Q502931) in your reference Remains of hybrid human girl with Neanderthal mother discovered in Siberian cave. What I'm missing? --Succu (talk) 15:07, 4 September 2018 (UTC)[reply]

What are you missing? My post with the time stamp of "22:42, 23 August 2018", it seems. "if you insist on the exact wording of your secondary sources" I do not. HTH. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:57, 4 September 2018 (UTC)[reply]

I deleted the wrongly sourced statement. --Succu (talk) 20:00, 4 September 2018 (UTC)[reply]

And I reverted you, because it is a sourced statement. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 05:47, 5 September 2018 (UTC)[reply]

BTW: Most of your claims raise a „type constraint“. As father of Denisova 11 (Q56464945) and mother of Denisova 11 (Q56464406), created by User:Yair rand (thx) do. --Succu (talk) 20:41, 4 September 2018 (UTC)[reply]

As I have said previously, bad constraints can and should be fixed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 05:47, 5 September 2018 (UTC)[reply]

Maybe archaic human admixture with modern Homo sapiens (Q4785541) helps for a more general understanding... --Succu (talk) 21:41, 4 September 2018 (UTC)[reply]

Subclass of gene flow (Q143089)? Involving H. sapiens? How does that help? Oh, and since you are concerned with „type constraints“, that has one. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 05:48, 5 September 2018 (UTC)[reply]

Link to commons wiki and conflict between gallery and category

Hi could you please remind me what is the standard procedure when I need to merge items such as Q2557858 and Q21162042? Shlìuld I remove the link to the category, keep the gallery in the final item.

Please consider that the majority of it-N users are quite practical nowadays, they basically avoid the creation of galleries on commons, they consider them difficult to update and time consuming, if they invest on something are the categories so most of the work of improvement of local items ends up connecting to commons categories.--Alexmar983 (talk) 19:24, 24 August 2018 (UTC)[reply]

If there's a Commons gallery, sitelink to it from the main item.

If there's also a Commons category, create a separate item for it with a label starting "Category:", and relate it to the first item by category's main topic (P301)/topic's main category (P910) in each direction.

Also add Commons gallery (P935) statements on both items linking to the Commons gallery, and Commons category (P373) statements pointing to the Commons category. On most Wikipedias, the software will follow these, in preference the sitelinks, so adding the P373 will be enough to make the sidebar link point to the Commons category.

On the Commons category, use c:Template:Wikidata infobox to create an infobox. This should automatically follow the sitelink and then the P301 to draw data from the main item.

A bit of a chore, yes; but it's the system we've come to, and it seems to work reasonably enough.

If there is no Commons gallery, and there is no category item already in existence (eg linked to a Wikipedia category, or to a category on a sister project), then it is acceptable to follow the simpler strategy of linking the Commons category straight to the main item. But this should be done only when the two conditions above are met; otherwise the full rigmarole as previous described is necessary. Jheald (talk) 23:11, 24 August 2018 (UTC)[reply]

Creating a new item for the category, with only a Commons sitelink, isn't permitted by Wikidata:Notability. It would be better to keep the category sitelink than replacing it with the gallery, in my opinion. But we've been through all this: I suggested a new policy of giving Commons sitelinks priority over galleries. But people said why not just make a category item for the sitelink, and if the notability policy forbids it, change the policy. So I proposed changing the notability policy, but it got no consensus. Ghouston (talk) 01:22, 25 August 2018 (UTC)[reply]

That restriction in WD:N is history. We now have thousands of items with just a wikilink to a Commons category, supporting an infobox there, and nobody is going to delete them. WD:N hasn't been changed yet, but the clause has a footnote noting that its continued application is questionable and pointing to open discussion on the talkpage. In practice the restrictive clause is dead, the message just hasn't reached the brain yet. Jheald (talk) 08:28, 25 August 2018 (UTC)[reply]

ok but this is getting confusing. I mean, I need to give newbies very clear tasks. And from this point of view, as long as the information is clear it can always be fixed later by bot. In any case the level of sophistication required by current users is increasing. They expect wikidata infobox and structured data more and more. So just to clear, current consensus is that i put the gallery not the category in the "other projects" section and I don't merge?--Alexmar983 (talk) 19:47, 25 August 2018 (UTC)--Alexmar983 (talk) 19:47, 25 August 2018 (UTC)[reply]

The two items you mentioned should be merged, since neither is a category item. Personally, I'd just leave the Commons category sitelink in place and add a Commons gallery (P935) statement for the gallery. Ghouston (talk) 00:11, 26 August 2018 (UTC)[reply]

The gallery hadn't been properly updated since 2011 (and only had low-resolution images when more + higher resolution ones were in the category), so I've redirected it to the category and merged the two items. thanks. Mike Peel (talk) 17:38, 26 August 2018 (UTC)[reply]

Wikidata infobox has a "qid" attribute which allows to draw in the information from whatever data item you assign it. I have used it on several categories leaving the link open for a gallery if and when they exist. It fixed a problem at source where the template assumes the link is a gallery and also pulls in the category if it is assigned. Since then, a bot has come through and re-assigned the link to the category and it is (as far as I know) simply not needed and ugly at source. It is an old and unnecessary war which I personally will defer to the gallery makers because the good galleries take a lot more work. The galleries with only one little fuzzy image on them are, I think, a response to being told to make the gallery, where the nice galleries are made out of choice and inspiration. Please leave this war with the galleries being the "winner". Also, the Category hack was beautiful, it worked just fine but I am not happy with the additional data entry when software can handle it just fine as it is. Having to choose gallery or category is a terrible thing. I did it a few times and I did not like it.--RaboKarbakian (talk) 20:49, 1 September 2018 (UTC)[reply]

Moveable dates

Moveable dates are dates like Easter or Hanukkah that change each year. There are many examples, all of the Jewish and Muslim holidays because they use a different calendar system. Moveable dates present difficulties on Wikipedia to update each year manually, so I created a template en:Template:Calendar date which reads in a JSON file en:Template:Calendar date/holidays/Hanukkah.js .. there are currently about a dozen of these JSON files but there could be 100s of even 1000s of moveable date holidays and events. Thus it's not practical to host the data files on Wikipedia. It seems like a logical fit for Wikidata. I don't know anything about WD. Are moveable dates something that would make sense for WD, and if so how to get started? I'm ready and able to write bots that generates/scrape the data and upload it to WD. -- GreenC (talk) 13:30, 25 August 2018 (UTC)[reply]

Sure: Q51224536 has definitions for dates of Easter Sunday.
--- Jura 20:05, 25 August 2018 (UTC)[reply]

Jura, that looks fantastic! I just created Q56251842, my first item creation, following your example. Now I need to figure out how to upload via bot.. and retrieve via Lua on enwiki. I will definitely be using your Easter data. -- GreenC (talk) 02:41, 26 August 2018 (UTC)[reply]

Jura, do you know how to create a range of consecutive days like Hanukkah has 8 days. -- GreenC (talk) 03:15, 26 August 2018 (UTC)[reply]

I might have been too short in my response:
- For things that can be defined through a regular pattern or an offset, I would use day in year for periodic occurrence (P837) instead. Values for P837 in 2018 should be found Wikidata:WikiProject_Calendar_Dates/lists/days/2018.
- I don't think we'd need Q56251842 as it can be defined with first Monday in September (Q14832552). BTW, that is linked from 3 September 2018 (Q45921181).
- For Hanukkah (Q130881), it might be sufficient to add 25 Kislev (Q11013530) to December 2, 2018 (Q45921937) (or December 3, 2018 (Q45921947)?). This way all dates for 2018 could be queried.

The problem with date of Easter (Q51224536) is that it can't easily be defined otherwise.
--- Jura 08:30, 26 August 2018 (UTC)[reply]

I think to do Hanukkah that way the user application would need foreknowledge that Hanukkah occurs in November and/or December, and for a given year search every day in those months until it finds 25 Kislev (Q11013530). Then the application would need to calculate 8 days hence (ie. foreknowledge of how long the holiday runs for) to find the last date of the holiday. Or am I misunderstanding how it's setup? I was hoping the application can be dumb about holiday specifics, with the intelligence loaded in the database 1-time so the application only needs to provide a year and a holiday name and get back the dates. -- GreenC (talk) 14:51, 26 August 2018 (UTC)[reply]

Not sure if LUA could do all that, but here is how it would look on query server: [4]
--- Jura 15:04, 26 August 2018 (UTC)[reply]

Not sure either. How would the query only retrieve Hanukkah (Q130881)? I tried adding ?item wd:Q130881 ?occ. below the ?holiday no luck. -- GreenC (talk) 16:19, 26 August 2018 (UTC)[reply]

I added definitions for three years and included it here. Obviously, all others would still need to be defined.
--- Jura 17:18, 26 August 2018 (UTC)[reply]

Ok wonderful. Let me see what I can do on the Lua side next. -- GreenC (talk) 18:13, 26 August 2018 (UTC)[reply]

Jura, This is what is available. I don't see a way to do queries. The way that looks possible (have not tried) is with mw.wikibase.getBestStatements( entityID, propertyID) .. like for Easter, it would be entityID Q51224536 and propertyID P585 - it would return all statements including date of Easter (Q51224536)point in time (P585)1 April 2018 -- GreenC (talk) 21:49, 26 August 2018 (UTC)[reply]

Hi Jura, it doesn't seem possible for Wikipedia Lua templates to use Wikidata for moveable date holidays/events, unless they are structured like the Easter example, as a separate entity. I don't know how Wikidata culture works, if it's flexible to end-user application requirements, or it be done a certain way within a Wikidata best-practice. I wouldn't want to upload the data as an entity, and change the template only to have the entity later removed. Can you provide any guidance or suggestions? -- GreenC (talk) 15:29, 27 August 2018 (UTC)[reply]

@GreenC: I think there are several tickets in phabricator that try to solve the underlying issue. As I wouldn't count on them working in the medium term, the solution you suggest it is feasible and if it was just for one holiday, it would be fine, but we might end up doing that for all of them. I might be able to provide an other approach in a few weeks, but in the short term, I can only suggest the following: you could generate a Listeria report on Wikipedia with the holidays you are interested in (e.g. like this one) and read that from the template. Alternatively, the MediaWiki date function might allow to get the date directly.
--- Jura 23:01, 27 August 2018 (UTC)[reply]
@Jura1: thanks. I think the template will take a multi-solution approach. There will be 3 ways to get date data. First a calculator that determines the Gregorian based on calendar offsets. The calculators will be third-party applications or plugins, anyone can write, the template doesn't do calcs itself. One already exists for Jewish holidays. If a calculator is not possible, such as with Easter and a few Jewish holidays, it will get the data from an entity such as the 'date of Easter'. If that is not available, it can fall back to using local JSON files to host the dates as last resort. Maybe later add a 4th option for Listeria bot, will keep it in mind for future expansion. -- GreenC (talk) 01:08, 29 August 2018 (UTC)[reply]
- @GreenC: Sounds good. Just to be sure which ones would be using something like Q51224536? I will try to get the ones with offsets working with queries.
  --- Jura 06:11, 29 August 2018 (UTC)[reply]

For Jewish holidays, this is what someone told me: "if you were not aware, between 1 Adar (or 1 Adar II in a leap year) and 29 Cheshvan, the number of days is always fixed. Therefore, any date can be derived as the addition or subtraction of a fixed number of days from the Rosh Hashana (or Passover) within the interval. Since Hanukkah, 10 B'Tevet and Tu B'Shvat do not fall within that interval, the calculation does not work for them. But it works for most everything else." (emphasis added). Adar I and II occurs during February (I) and March (II) and Cheshvan between October–November - you can see why I didn't want to write calculators :) Anyway, a holiday outside that window, such as Hanukkah can't be calculated, though maybe it can using Wikidata? -- GreenC (talk) 13:27, 29 August 2018 (UTC)[reply]

w:Hanukkah has "25 Kislev / 2018 date Sunset, 2 December" and {{#time: xjj xjF | 2 December 2018 }} gives "24 Kislev", so it seems to be possible with MediaWiki. Obviously, it don't know how reliable any of that is, but I think anything that moves with a calendar should be doable without storing all dates explicitly.
--- Jura 13:39, 29 August 2018 (UTC)[reply]

Well if you believe it is possible to make a calculator, for now I will use local JSON files storing the dates, and wait for someone to make a calculator, or until I figure it out. Here is the cfg file, you can see some holidays are using "datatype:calculator" with "datasource" being the calculator. Hanukkah uses "datatype:jsonlocal" and "datasource" points to the JSON file Hanukkah.js (which needs to be fixed work in progress). If at some point it's determined a calculator is not possible, then the data can be uploaded to a WikiData entity like Easter, "datatype" set to "wikidata" and "datasource" the entity "Q" number. -- GreenC (talk) 15:43, 29 August 2018 (UTC)[reply]

Song and clip, one or two items?

Hi,

Quick dumb question: should we have one or two items for a song and its clip?

I would have gone with two items to be clearer but I see that it's sometimes mixed in only one item (eg. there is 11 single (Q134556) with coordinate location (P625)).

Cdlt, VIGNERON (talk) 13:59, 25 August 2018 (UTC)[reply]

Apple Music music video ID (P5655) has just been created with the idea in mind that music videos would eventually be separated from the musical work they cover. Thierry Caro (talk) 15:14, 25 August 2018 (UTC)[reply]

@Thierry Caro, VIGNERON: As far as I'm aware, singles, songs and music videos should all be separate entities (see the music video items linked to from Apple Music music video ID (P5655), for example – I also did some work on separating song and single for those topics). Music videos may have director (P57), songs may have tonality (P826), and songs and singles may both have charted in (P2291) depending on the methods of particular record charts. (Sitelinks should normally be hosted by the song's item, and songs, singles and videos can all have has edition or translation (P747), as far as I'm aware.)

Furthermore, none of them should have a coordinate location (P625), since they are all abstract entities without obvious physical referents. However I think a P625 could be added as a qualifier to a filming location (P915)/recorded at studio or venue (P483) statement, if the precision can be higher than that of the location item's P625. See also Wikidata:Project chat/Archive/2018/08#Property constraints – music releases. Jc86035 (talk) 18:50, 25 August 2018 (UTC)[reply]

Thanks @Thierry Caro, Jc86035: and how would you link a song to its clip (and/or vice versa)? Cheers, VIGNERON (talk) 11:04, 28 August 2018 (UTC)[reply]

I'm not sure. Maybe

⟨ clip ⟩ manifestation of (P1557) ⟨ song ⟩

? But I'd be interested in other comments. - Jmabel (talk) 15:30, 28 August 2018 (UTC)[reply]

@Jmabel, VIGNERON: I've used part of (P361) on song items and has part(s) (P527) on video items (this would be done for films containing songs as well;time index (P4895) might already be used for this as qualifier to indicate when a track starts playing, but I'm not sure if the property's supposed to be used like that). Jc86035 (talk) 08:19, 29 August 2018 (UTC)[reply]

On the other hand this might be too simplistic if only part of a track is used. Jc86035 (talk) 08:20, 29 August 2018 (UTC)[reply]

part of (P361)/has part(s) (P527) is an interesting way to do this; do you feel this is generally accepted practice (and should be documented as a guideline) or just a personal choice? - Jmabel (talk) 15:37, 29 August 2018 (UTC)[reply]

@Jmabel: I think it was because it was done this way on Thriller (Q380825), which is one of the example items, and it made sense to me so I used it on the items that I worked on. I think the use on Thriller (Q380825) is actually incorrect, though, since the version of "Thriller" used in the music video is different to both of the versions for which Wikidata items currently exist. The audio of the entire music video (not just the part comprising the song) might also have been separately released (I don't know if this is the case). For the music videos for which I created items, all contain the entire uninterrupted audio track of the song. Jc86035 (talk) 16:51, 29 August 2018 (UTC)[reply]

@Jc86035: I'd rather see a more specific pair of properties for this. It's common enough that we should probably eventually have tens of thousands of these, so I think the specific relationship of a piece of music being used in a video specific to that piece of music merits distinct properties. - Jmabel (talk) 22:35, 29 August 2018 (UTC)[reply]

@Jmabel: I think it would be useful to have a property or two for the use of a full audio track in a film/video, as well as for a non-repetitive but truncated use of an audio track in a film/video. However, since songs can have multiple music videos and music videos can contain multiple songs, I think having properties for the relationships "the music video for this song" and "the song of this music video" would be too specific. Jc86035 (talk) 07:50, 30 August 2018 (UTC)[reply]

Q56222412

Asia Carra is a young italian singer born in Beijing so she is half Italian and half Chinese. It is exact for the English grammar write “Italian Chinese”? Or there is a different mode? --151.95.37.112 18:47, 27 August 2018 (UTC)[reply]

If she's a citizen & resident of Italy, we'd definitely say "Chinese-Italian" or "biracial Chinese-Italian". Similarly, if she's a citizen & resident of China, we'd definitely say "Italian-Chinese" or "biracial Italian-Chinese". Other combinations get trickier to express so succinctly. - Jmabel (talk) 19:48, 27 August 2018 (UTC)[reply]
Do you have a reference that says she's both Italian and Chinese? You don't necessarily get the nationality of the place you are born or live. I can't find anything on the web except for a few youtube videos. Ghouston (talk) 06:09, 28 August 2018 (UTC)[reply]
- Ah, yes, I didn't even consider that. If her parents are both Italian, and they merely happen to have been living abroad when she was born, she's simply Italian. - Jmabel (talk) 15:36, 28 August 2018 (UTC)[reply]
  - But she is Chinese native speaking - or near native. The Chinese are say she speaks better than they themselves. --151.95.37.112 06:31, 29 August 2018 (UTC)[reply]
    - That can go in languages spoken, written or signed (P1412). When you say "Chinese are say she speaks better than they themselves" you are basically saying she isn't Chinese. Ghouston (talk) 10:55, 29 August 2018 (UTC)[reply]

Fixing the search to be useful again; aka making the simple, simple again

In times gone by, one used to be able to do a simple search for a person by partial name and partial data field, eg. throw in a year of birth. Great functionality if you were looking to match someone, or knowing to create someone, etc.

For example, something like "Bonaparte 1769" would find Napoleon (Q517) Now? NADA!

If you want simple people to help, you have to retain the simple and useful features. Sometimes the geniuses here aim for the high end, and forget the simple tasks. How are people meant to prevent duplicates when the simple things are made so hard? If the simple things are hard, people will just walk away. — billinghurst sDrewth 00:15, 28 August 2018 (UTC)[reply]

You still have that simple search capability, but you need stay in Wikipedia and use Wikipedia search, or on Commons, and if you scroll all the way to the bottom you will see the clickable Q results. However, in the example you gave, you first pull up all the objects and research papers on Bonaparte. Wikidata has not only changed search, but has grown so exponentially that you get lost in the results. You can better run your own simple query script. In my field of interest (paintings) I use the same search time and again, so I have become a fan of the SQID tool to look up museum paintings like this. Jane023 (talk) 06:59, 28 August 2018 (UTC)[reply]

If that's the correct answer, that's a bad situation. The ordinary search ought to be something readily used by newbies and give reasonably accurate and naively expected results. - Jmabel (talk) 15:38, 28 August 2018 (UTC)[reply]

There is no "correct" answer, but personally I haven't used search much the past few years and prefer to use Google to search Wiki(p/m)edia projects, since Google shows me stuff not labelled in my search language. Jane023 (talk) 16:18, 28 August 2018 (UTC)[reply]

"Correct answer" as in "if you answered his question correctly". - Jmabel (talk) 22:14, 28 August 2018 (UTC)[reply]

Yes of course this is open to interpretation. I suppose the most succinct correct answer then is: No, something like "Bonaparte 1769" would probably not have found Napoleon (Q517) a few years ago, because the birthdate was not findable as text, either in that shortened form, or with the birthday included. Jane023 (talk) 08:03, 29 August 2018 (UTC)[reply]

If the basics in search cannot be done, then what is the point? Sending someone to a third party search function is just weird. Searches as described used to work, and now they don't. I was going to give examples, but in the end, it is just bashing one's head onto a wall, and of that I have had enough. I don't see it working well for the sister wikis any more, with little benefits for lots of input. I feel that it matters NOT to others here. Some of us want to do our work at the other wikis, and have it work well here. I don't see that the reverse is the case. Have fun, it seems that the mission has changed. — billinghurst sDrewth 08:15, 30 August 2018 (UTC)[reply]

@billinghurst: I just checked through the page history for Napoleon (Q517), and on the wikidata side, 1769 was NEVER in one of the labels or descriptions. The only way wikidata search ever would have found it with your query would be if one of the sitelinks had "1769" in its title - which is possible. But wikidata search has only ever searched labels, descriptions, and sitelink titles - it has never searched the values of statements. See Phabricator ticket T163642

Tracked in Phabricator
Task T163642

for an effort to improve that recently, although in my opinion it went astray - but it's trickier than it sounds to do what seems obvious here for a variety of reasons. ArthurPSmith (talk) 18:51, 30 August 2018 (UTC)[reply]

It was an example only, one picked out of the blue. Don't worry, I have had enough and I am predominantly gone, and no longer involved in the politics here. If simple search isn't important to you on site, that is your business. — billinghurst sDrewth 01:40, 31 August 2018 (UTC)[reply]

Hmm, I think you are misunderstanding my comment? Simple search is very important to me - but it's much harder here than on the wikipedias because the "pages" we see are not plain text, they are data which looks different in different languages. I suggested an approach on the phabricator ticket to handling this, but it was tried and breaks for at least some identifier cases. It's not clear what the right method is. If you have a specific suggestion here, I'm sure it would be very welcome on the phabricator ticket! ArthurPSmith (talk) 15:58, 31 August 2018 (UTC)[reply]

Dutch bot descriptions generally include year of birth and year of death. So many items about people could be found thanks to that. Q517 doesn't have that though.
--- Jura 16:09, 31 August 2018 (UTC)[reply]

Jane023 said "Wikidata has not only changed search, but has grown so exponentially that you get lost in the results". I have a little proposal to solve partially this problem: enable users to cut off the advanced search results they are not interested in allowing them to totally exclude items of certain highly specific types, e.g. instance of (P31)scholarly article (Q13442814) or instance of (P31)taxon (Q16521) or instance of (P31)asteroid (Q3863). I hope this possibility will be taken in consideration. --Epìdosis 16:24, 31 August 2018 (UTC)[reply]

Ha! That would nice but I also feel that in another 5 years there will be other even larger datasets added, so you will keep having to turn of more and more search areas or "ontology trees". But maybe by then Wikipedia search will have improved so that when you search for specific things not in Wikipedia (yet) it will pick up all related articles, including related Q numbers, with or without matching search text. Jane023 (talk) 17:48, 31 August 2018 (UTC)[reply]

@Epìdosis, Jane023: I've suggested something along those lines too - basically supplementing the namespace filtering (i.e. Items vs Properties, Lexemes, Wikidata proper, etc) that wikimedia software naturally does out of the box with the ability to filter on classes (P31/P279 category) - but technically I think that's also very hard to do... Note wikibase IS open source software that anybody willing to work on this could try contributing to! ArthurPSmith (talk) 18:14, 31 August 2018 (UTC)[reply]

Category:Swedish words prefixed with ytter-

Category:Swedish words prefixed with ytter- (Q56276138) was recently created, and now has categories on English and Norwegian Wiktionary linked to it. However, the English category is named "prefixed with" while the Norwegian category is named "som starter på" (beginning with). Being prefixed with something is not the same as merely beginning with something. The definition used in the English Wiktionary is that "prefixing" means that the word is formed by prefixing, not the mere presence of some prefix. The English word bevel begins with be- but it's certainly not prefixed with be- the way become is! Rua (talk) 11:48, 28 August 2018 (UTC)[reply]

To clarify further: English Wiktionary considers forget to be prefixed with for-, but forgetful is not considered to be prefixed (instead it's considered suffixed with -ful). Rua (talk) 11:59, 28 August 2018 (UTC)[reply]

The name could possibly be clearer, and we'll keep that in mind for further changes (it concerns a number of categories, and changing the naming convention isn't a one-minute job). However I can confirm that the intention of all som starter på categories on no-wikt is corresponding to the English prefixed with, and equally som ender på is corresponding to the English suffixed with. In this case forgetful would be categorized in no:wikt:Kategori:Ord i engelsk som ender på «-ful». A possibly better name would be dannet ved prefikset (rp. dannet ved suffikset) maybe ... but when changing the naming convention we'll make sure to move all categories so the Wikidata entry should be correct anyways. Mewasul (talk) 10:49, 29 August 2018 (UTC)[reply]

Merge instructions - where?

So I tried to add an article to an item and got a warning message saying it was already in another - but if there were really both the same merge them. But the warning did not link to any description of how to merge them. By trial and error, I got two sets of two into one set of four (Q1863530) - with a mostly empty item still hanging around: (Q27664520). How do I get rid of that? Which one should I have chosen as the merge target? Why doesn't the warning message give any guidance? Rmhermen (talk) 16:17, 28 August 2018 (UTC)[reply]

Rmhermen, the page Help:Merge explains the different ways to merge items. And, the target item should be the one who is not obsolete. Esteban16 (talk) 18:30, 28 August 2018 (UTC)[reply]

Why doesn't the error message link to this explanation, though? Rmhermen (talk) 14:40, 30 August 2018 (UTC)[reply]

Doesn't it: MediaWiki:Wikibase-error-sitelink-already-used? Matěj Suchánek (talk) 13:18, 3 September 2018 (UTC)[reply]

several job openings in or around the Wikidata dev team

Hey folks :)

We have a number of open positions at the moment at WMDE that are relevant for Wikidata including a program manager for Wikidata who will work closely with me. I'd love to see many applications from people who already are a part of the community and understand and love what makes Wikidata special. Find the full list including job descriptions here. If you have any questions please let me know.

Cheers --Lydia Pintscher (WMDE) (talk) 19:07, 28 August 2018 (UTC)[reply]

Implementation of a new Wikidata-to-OSM service for P402

Please, do you support the implementation of a new Wikidata-to-OSM service for OpenStreetMap relation ID (P402)?

Explaining. The new service will solve the cited problem of "only relations": will be possible to link OSM Map Features represented by nodes or ways.

The new server must be hosted at the Openstreetmap-side, but needs the support of the Wikidata community also. The service will redirect Wikidata item "Q" identidiers by http://osm.org/Q$1 (or wikidata.osm.org or other) to the respective geometry. Examples:

Relation. The Wikidata item that represents the concept of the country Brazil (Q155), on OSM is a relation,
http://osm.org/Q155 will redirect to https://www.openstreetmap.org/relation/etc
Way. The Wikidata item that represents the concept of the Fraternity Bridge (Q2679759), on OSM is a way,
http://osm.org/Q2679759 will redirect to https://www.openstreetmap.org/way/etc
Node. Wikidata item of the Number zero survey marker of the city of São Paulo, (Q10325364), on OSM is a node,
http://osm.org/Q10325364 will redirect to https://www.openstreetmap.org/node/etc

See more details at the wiki.openstreetmap.org Proposal-QID. --Krauss (talk) 13:39, 29 August 2018 (UTC)[reply]

It looks like a nice idea. Have you thought about hosting it on Toolforge? NMaia (talk) 15:47, 29 August 2018 (UTC)[reply]

Maybe this is something that toolforge:hub could do? @maxlath might be interested. Sam Wilson 00:21, 30 August 2018 (UTC)[reply]

@Samwilson: You can indeed use toolforge:hub to generate URLs to OSM relations from Wikidata IDs (example: https://tools.wmflabs.org/hub/Q155?property=P402 ) but it doesn't work for ways or nodes as we don't have properties for those (right?). Note that if we had those properties, the link could simply include the different possible properties (example: https://tools.wmflabs.org/hub/Q155?property=P402,PXXXX,PYYYY )-- Maxlath (talk) 11:11, 5 September 2018 (UTC)[reply]

I don't really understand what this is intended for. What does it have to do with OpenStreetMap relation ID (P402)? What will you do when multiple OSM objects have the same Wikidata ID? Personally I would really like to see OSM support searching by Wikidata IDs, so that we can enter Qxxx or wikidata=Qxxx into the search box, that would give us short copyable URLs as a side effect. - Nikki (talk) 12:47, 30 August 2018 (UTC)[reply]

The OSM assumption that Wikidata Q-numbers represent "unique and eternal" identifiers for their objects is blatantly wrong. That's why they need to implement unique IDs for their elements, so we can manage the links to their elements from within Wikidata. This issue concerns for example all the items of museums, archives, libraries, cultural venues and the like which confound the geographical object and the organization. This typically is the case for Wikidata items that were created based on Wikipedia entries and their categories (i.e. tens of thousands of items). On Wikidata, we will end up disentangling these items and their statements, which will "break" the OSM-WD link that they have set on the OSM side with 50% probability. That's why we should be able to assign the OSM-ID explicitly on the WD-side and have an automatized service in place that handles the discrepancies between OSM and WD whenever objects and identifiers get moved around on the WD or the OSM side. --Beat Estermann (talk) 13:53, 30 August 2018 (UTC)[reply]

@Beat Estermann: "unique and eternal" is indeed strange but I'm not sure it's « blatantly wrong ». At least a Qid is unique, that's for sure and most of the item it's perennial (but indeed not eternal), especially if you keep in mind that OSM have current objects.

For the GLAMs who are a geographical object and organization, that's why I'm often creating two items, one for each (and I do the same on OSM too). Or splitting when there is only one item and I need to put separate informations (typically for inception (P571) who is the date of construction in the context of a building and the date of creation for an organisation).

For assigning from the WD side it would be ideal, but how to do? As a reminder, when you edit an OSM object, the identifier can change too (which is quite painful... in this sense, it's very understandable than an OSMer thinks that Qid are "eternal").

Cdlt, VIGNERON (talk) 19:23, 30 August 2018 (UTC)[reply]

Using Wikidata IDs on OSM objects is the currently best way to guarantee a link between OSM objects and Wikidata concepts. The 'burden' of maintenance is on editing the OSM objects, like it is done for transit relations. OpenStreetMap relation ID (P402) is not the best way to have a permanent correlation because also relations can break and change ids in OSM. The "permanent id" discussion can be solved by a service, yes, but to actually solve it the service would need to be as much automatic as possible, otherwise it's simply a case of moving the problem around. Perhaps the OSM API can be extended to deal with this. --Sabas88 (talk) 09:14, 4 September 2018 (UTC)[reply]

Duplicate creation by GZWDer_(flood)

There is a discussion about the ongoing creation of duplicates by GZWDer_(flood) at Wikidata:Administrators'_noticeboard#Please_block_Special:Contributions/GZWDer_(flood). Essentially, the user chose to change the approach with PetScan and create new items even if there are already existing items with the same name. This instead of using Duplicity. The user is known for leaving it to others to clean up after their sprees. Please comment there if you don't mind (or if you do mind).
--- Jura 21:20, 29 August 2018 (UTC)[reply]

Question about mass adding properties into wikidata

So some of my suggested properties for wikidata have recently be approved, how can I add those properties into related wikidata entries relatively quickly? C933103 (talk) 23:18, 29 August 2018 (UTC)[reply]

@C933103: it depends what your data source is. If you want to extract them from Wikipedia articles, try Harvest Templates. If you want to import the data from a tabular file, try OpenRefine. For more background, see Wikidata:Data_Import_Guide − Pintoch (talk) 10:35, 1 September 2018 (UTC)[reply]

@Pintoch: I am talking about properties of external identifiers. Also, it seems like that Harvest Templates tool cannot be used to harvest wiki not run by WMF?C933103 (talk) 14:51, 1 September 2018 (UTC)[reply]

Puerto Rican nationality

Today, I have removed the country of citizenship property on many Puerto Rican people items, because they wrongly value "Puerto Rican" as the nationality, but it should be "American". AFAIK, Puerto Ricans are citizens of the U.S, althought to get real citizenship (such as voting) they must live in the mainland. When valued "Puerto Rican", the property displays a message error. There must be many more items with this mistake, and I think a bot could easily fix them. Esteban16 (talk) 00:20, 30 August 2018 (UTC)[reply]

This query gives 1009 items which are citizen of Puerto Rico. Perhaps some of them predate the US takeover in 1899. Before that they would have been Spanish? Ghouston (talk) 01:35, 30 August 2018 (UTC)[reply]
It would probably be better to change all the citizenship claims to residence (P551) of Puerto Rico, instead of just deleting the link with Puerto Rico. It may not be correct in every case, but it's a start. Ghouston (talk) 01:40, 30 August 2018 (UTC)[reply]

Ghouston: That is a good idea, too. And yes, they had Spanish citizenship for a while. The Jones–Shafroth Act granted Puerto Ricans American citizenship on 1917. Esteban16 (talk) 02:07, 30 August 2018 (UTC)[reply]

@Esteban16: However, according to Wikipedia article w:en:Puerto_Rican_citizenship, "The United States government also continues to recognize a Puerto Rican nationality". @Ghouston: I don't think it is a must for everyone with Puerto Rican nationality to keep living in Puerto Rico? C933103 (talk) 02:25, 30 August 2018 (UTC)[reply]

It's definitely not "a must". I would think Puerto Rican citizenship should be recorded in Wikidata, although possibly (from 1917 onward) in conjunction with U.S. citizenship. Jmabel (talk) 03:29, 30 August 2018 (UTC)[reply]

The article also says Spain continues to grant citizenship to Puerto Rico citizens. Interesting. Ghouston (talk) 06:32, 30 August 2018 (UTC)[reply]

Then it seems removing the property from some items was wrong, and I think as same as User:Jmabel, the nationality should be recorderd. Esteban16 (talk) 11:04, 30 August 2018 (UTC)[reply]

w:en:Puerto_Rican_citizenship is a seriously flawed article, and should be ignored. I don't know what the situation is for Puerto Rico citizenship (if it currently exists), but for US states, the 14th Amendment to the United States Constitution states in part "All persons born or naturalized in the United States, and subject to the jurisdiction thereof, are citizens of the United States and of the State wherein they reside." So if a US citizen resident permanently moved from Puerto Rico to a state, she would become a citizen of that state. If a US citizen resident of a state permanently moved to Puerto Rico, he would cease to be a citizen of the state. Citizenship in a state is not a nationality. Jc3s5h (talk) 13:07, 30 August 2018 (UTC)[reply]

@Jc3s5h: You are certainly right about the states here, but I believe you are wrong about Puerto Rico (which is not a state). I believe someone born in Puerto Rico retains Puerto Rican citizenship even if they leave (while also being a citizen of any U.S. state they may reside in), and in particular this is relevant to the Spanish recognition of Puerto Rican citizenship. Do you have any citation to the contrary? - Jmabel (talk) 15:16, 30 August 2018 (UTC)[reply]

Jmabel, I do not have sources concerning Puerto Rican citizenship. But of course the burden of producing reliable sources falls upon those who want to state a claim in Wikidata; it is not the responsibility of other editors to disprove claims which lack such sources. Jc3s5h (talk) 15:30, 30 August 2018 (UTC)[reply]

https://aldia.microjuris.com/2013/08/30/la-eficacia-y-alcance-del-certificado-de-ciudadania-puertorriquena/ (in Spanish, cited in the English-language Wikipedia article) looks pretty solid to me. There is a specific certificate of Puerto Rican citizenship, and rights to favorable status for gaining Spanish citizenship based on place of birth being Puerto Rico (not needing to renounce prior citizenship) or any other Ibero-American territory. The portion there about "naturales de Puerto Rico estamos incluidos" suggests strongly (though it doesn't state outright) that this would be about place of birth rather than place of residence, so a different criterion than a U.S. citizen becoming a de jure citizen of whatever state they reside in.

I don't have time right now to check out every source of the en-wiki article; do you have specific claims there that you doubt? "...is a seriously flawed article, and should be ignored" is a pretty vague critique, and does not leave me a lot to respond to, short of researching or re-researching an entire article myself. - Jmabel (talk) 20:49, 30 August 2018 (UTC)[reply]

Unfortunately I don't speak Spanish. When I read some of the English sources from the article, the sources seemed biased toward a considerable degree of separation between Puerto Rico and the rest of the United States, and didn't seem to clearly support the claims that were just before the footnotes. After I wrote my comment above, I located the current directions (written in Spanish) from the Puerto Rican government to apply for a Puerto Rican certifiate of citizenship. I ran it through Google Translate, and the gist of it sees to be that a US citizen who was born in Puerto Rico, or a US citizen who was born elsewhere but has lived in Puerto Rico for at least one year immediately prior to applying, is eligible for the certificate. Jc3s5h (talk) 00:02, 1 September 2018 (UTC)[reply]

And apparently any benefits that Puerto Ricans may obtain in Spain are limited to "natural born" citizens of Puerto Rico, not just any US citizen who spends a year there. Ghouston (talk) 04:41, 1 September 2018 (UTC)[reply]

@Ghouston: That is correct. I hadn't realized that you could get the certificate just by being resident, so this may work out differently than I thought: if it provides no information beyond place of birth, it's less relevant. Not stated in the article I had cited, and I hadn't tried following up a ton of sources. Probably should be clarified in the en-wiki article. - Jmabel (talk) 16:14, 1 September 2018 (UTC)[reply]

@Jc3s5h: Thank you for now bringing up something substantive, rather than just a claim that the en-wiki article is crap. - Jmabel (talk) 16:14, 1 September 2018 (UTC)[reply]

There are also plenty of references in that Wikipedia article supporting what the article describe.C933103 (talk) 22:10, 30 August 2018 (UTC)[reply]

Please don't try to standardize for the sake of standardizing. As Puerto Rico doesn't really fit the traditional categorization of sovereign states and nationalities, it is unhelpful to make a blanket rule on whether Puerto Ricans should be recorded as having Puerto Rican citizenship or U.S. citizenship. If in conflict, consult biographical sources about the person. Deryck Chan (talk) 22:26, 30 August 2018 (UTC)[reply]

Deryck Chan, people raised in Puerto Rico are commonly referred as "Puerto Rican", regardless if they live there or not (i.e. Ricky Martin), and without providing a nationality in the case they reside in Puerto Rico. Esteban16 (talk) 00:00, 31 August 2018 (UTC)[reply]

That's also the case for a lot of places without official citizenships, like Scotland and Tasmania. Ghouston (talk) 04:32, 31 August 2018 (UTC)[reply]

Except it's more like sub-sovereign entities like Jersey and Hong Kong, where citizenship of these entities is legally recognised as a different kind of citizenship from citizens of the main country of that sovereign state that holds it. It's a different class of citizenship and it would be against the principle of original research if we refuse to recognise these citizenships categories. Deryck Chan (talk) 09:20, 31 August 2018 (UTC)[reply]

This has been discussed enough but no solution has been provided. According to the property, the statements could be a state, a nation or a fictional country. It seems Puerto Rico does not belong to any of them, and I think it should not be considered a nationality, as they are American citizens. If we are not agree about this, then consensus should be made. The property currently has issues in all those items, and it should be fixed ASAP. Esteban16 (talk) 22:33, 31 August 2018 (UTC)[reply]

From the article, it seems like one can at the same time be an PR citizen & US citizen & PR national & US national.C933103 (talk) 11:34, 1 September 2018 (UTC)[reply]

May I presume that "fictional county" above means to say "fictional country"? - Jmabel (talk) 16:18, 1 September 2018 (UTC)[reply]

Yes, Jmabel, it was a mistake. Esteban16 (talk) 16:26, 1 September 2018 (UTC)[reply]

Most of us agree with the fact "Puerto Rican" is not a nationality. Then, should I proceed with requesting the bot task to remove the property from the items? Or, should it belong to the property? Esteban16 (talk) 18:36, 2 September 2018 (UTC)[reply]

@Ghouston, C933103, Jmabel, Jc3s5h, Deryck Chan: Pinging users who participated in the thread. Esteban16 (talk) 01:06, 3 September 2018 (UTC)[reply]

I don't see why it being not a nationality is relevant. If there is a relevant legal status as citizenship of Puerto Rico, shouldn't it be included? We can have multiple citizenships given for a single person, and the constraints can be modified if they don't reflect the concept correctly. --Yair rand (talk) 04:15, 3 September 2018 (UTC)[reply]

I can't see how you come up with the conclusion that most of us agreed on that.... C933103 (talk) 06:06, 3 September 2018 (UTC)[reply]

I disagree with the summary that 'Most of us agree with the fact "Puerto Rican" is not a nationality.' In fact I am of the view that we should allow Puerto Rico to be listed as a country of citizenship, particularly for people who self-identify as such by reliable sources or by participation in international event as Puerto Rican (rather than USA, or Spanish in the past) representatives. This doesn't exclude them from also being listed as having USA (or Spain, or any other country that the person holds citizenship of) as country of citizenship. If we need to "fix" the constraint then I would broaden P:P27's value type constraint. Deryck Chan (talk) 08:58, 3 September 2018 (UTC)[reply]

off-topic a bit, how to treat sub-nation such as Puerto Rico seems a more off-shot discussion. For example, Bermuda had their own en:British passport (Bermuda), as well as the existence of en:British National (Overseas). So, given reliable source to verify, how to properly treat those "sub-class" of nationality of an empire or "federation of state"? British National (Overseas) were either de facto stateless (some ethnic non-Chinese minority thus they can exchange the status from BNO to BC) or ethnic Chinese. The Chinese, after 1997 had de jure automatically qualified (or became) as China PR citizen. But it seem wise to list them under value "British Hong Kong" as depreciated value. Also, for all other former colony, at that time there is no separation of nationality in the law of the empire, thus how to treat them, filling en:Gold Coast (British colony)? or British subject for those obtained British nationality before independent ? Matthew hk (talk) 06:42, 3 September 2018 (UTC)[reply]

Equivalent to e.g Property:GND for Wikidata Object IDs?

What is the property that holds Wikidata Object IDs? I would like to use a property Wikidata Object ID on an external website but I am not able to find the equivalent property here that is defining the URI formatter or the regexes etc. Obviously you are not using it here since this would be a self-reference however Wikidata is big and important enough to get a respective property I guess. Thanks for your infos and help. Cheers --[[kgh]] (talk) 14:15, 29 August 2018 (UTC)[reply]

Hmm, please let me rephrase: What the the property for Wikidata-IDs? --[[kgh]] (talk) 17:53, 31 August 2018 (UTC)[reply]

Ah, sometimes if you rephrase you end up giving the search another shot with the new term. Found it: Q43649390. --[[kgh]] (talk) 17:55, 31 August 2018 (UTC)[reply]

Splitting country of citizenship (P27)

I just realized that the English description for P27 is "country of citizenship: the object is a country that recognizes the subject as its citizen.". And then, in some other languages, the word "nationality" also appeared in description. Such description would cause numerous problems:

For instance when someone is a citizen of a non-widely recognized country, and then when that non-widely recognized country appear as a value for the property, someone who are against the existence of that country might dispute it and replace the value with countries that claims to control the area
Or if the subject is a citizen of a dependent territory or other area that are not a country in itself, the property cannot be used to reflect such situation
And see w:WP:Citizenship and nationality for one of the attempted explanation for difference between "nationality" and "citizenship"

As such, in order to properly describe those subjects, please separate the property for "nationality" and the property of "citizenship" into multiple properties. C933103 (talk) 09:49, 30 August 2018 (UTC)[reply]

"Nationality" seems suspiciously like a way of associating people with countries based on somebody's arbitrary judgement that they belong with that country. If it's just country of birth, we already have a separate property for it. If it's not country of birth, how is it defined exactly? Ghouston (talk) 10:55, 30 August 2018 (UTC)[reply]

I don't think the "country of birth" part in that proposal make a lot of sense since there are countries that do not determine nationality according to country of birth. There seems to be multiple definition for what the term "nationality" could mean. In some cases it is a legally defined term that comes with rights and duties, while in other cases it might also be the case, and in some cases it could even be arbitrarily decided by individuals. For instance, For British person, they are UK citizens but they are English/Scottish/Welsh/N.Irish/etc. nationals according to my understanding although they are not legally defined if I didn't miss anything. It is obviously helpful to include such information in wikidata but then "how" would be the problem. Another example is that, for a citizen in Hong Kong, as Hong Kong is not a country so it cannot be a value in P27, the P27 value for those subject can only be China/UK/India/nil/etc., with an additional property saying the subject is a "permanent resident" of Hong Kong which might not sufficiently explain the status of it being equivalent to citizenship of Hong Kong in most cases.C933103 (talk) 11:37, 30 August 2018 (UTC)[reply]

Ad 1 and 2: Since when are contradicting statements a problem on Wikidata? – If a fact is disputed and there are valid sources for either view, just enter the contradictory statements. I don't think we'll be able to resolve the type of cases you are mentioning by refining the definitions.

Ad 3, I don't see the problem with country of citizenship (P27); the labels and descriptions look ok. There are a few (pseudo-)nation states that confound the concepts of citizenship and nationality/ethnic group, and this is reflected in their language (thus the primary label of "country of citizenship" in French is "pays de nationalité").

There also is ethnic group (P172), which in my understanding largely covers the concept of "nationality" stripped of its meaning of "belonging to a country".

Cheers, Beat Estermann (talk) 13:20, 30 August 2018 (UTC) If anybody wonders what I mean by pseudo-nation state, here you go: Willensnation (Q694366)[reply]

How about when the value is clearly not a country like, let say, French Polynesian? The French translation have been adjusted according to what you said, however in English it would still say "Country of citizenship: French Polynesia" when French Polynesia isn't a country.
P172 is ethnicity. It is still a very political term and sometimes there are even special legal definition that restrict it in some rather strange ways. Like if someone from Taiwan try to claim his ethnicity is Taiwanese, then he could be considered as a radical separatist by China, and if the situation occurs within China then the person could face severe administrative punishment. C933103 (talk) 13:57, 30 August 2018 (UTC)[reply]

Ad 1: country of citizenship = France; nationality / ethnicity = Polynesian.

Ad 2: why do you think the term "nationality" is less prone to that type of problem?

--Beat Estermann (talk) 14:13, 30 August 2018 (UTC)[reply]

So, a French Polynesian if supposed to fill France in P27 as country of citizenship, then how about when someone immigrated to French Polynesia? I am pretty sure ethnicity won't change due to immigration, but what sort of property would describe the subject's status as part of French Polynesia? Like if the subject is an Indian immigrating to French Polynesia, his ethnicity will still be Indian regardless of his status, and wouldn't be an ethnically Polynesia according to my understanding.
Using Taiwan as example, in 1992 cross strait talk a consensus have been reached that would enable both sides to express themselves as being part of China and by extension to that the P27 of Taiwanese subject can be described as "Republic of China" in Chinese label to show its different from People's Republic of China. As long as individuals continue to claims the scope of "Republic of China" is not an entity separated from mainland China then it would be slightly more politically acceptable. (Although still not strictly acceptable)
- Note:The situation described above was only to illustrate how ethnicity can also be politically sensitivity, the proposed nationality-citizen split will most probably not be used on subject of Taiwan.
  - Edit: Actually I should have used myself as an example. Given that myself is a
    1. People's of Republic China national, which mean People's Republic of China citizen
    2. "British National Overseas", which is NOT British Citizen and would not be treated as UK National by numerous authorities including EU
    3. Permanent Resident of Hong Kong, which also represent most of the citizen right in the territory
    4. Ethnically Han Chinese, belong to the sub-ethnic group of Canton
  - In the current wikidata structure, if I somehow become notable enough to get a wikidata entry about myself, that entry will only feature P27: PRCHina, Ethnicity: Han Chinese, Permanent Resident: Hong Kong, which is not very descriptive about the actual situation of such a subject like myself. People who are familiar with the situation of the territory can easily infer what these value mean however that would require such background knowledge to fully understand these wikidata values.

C933103 (talk) 22:09, 30 August 2018 (UTC)[reply]

The only thing you would seem to be lacking is a way to represent "British National Overseas". Maybe just use British National (Overseas) (Q5613380) in country of citizenship (P27)? No, I guess that wouldn't work because of the way the value of country of citizenship (P27) is formulated to be a country. Ghouston (talk) 00:04, 1 September 2018 (UTC)[reply]

See prior discussions Wikidata:Property proposal/Nationality, Wikidata:Project_chat/Archive/2017/08#How_to_look_up_persons_nationality.3F. "Nationality" is not a workable property. --Yair rand (talk) 19:56, 30 August 2018 (UTC)[reply]

What about only allow the use of such property when they are legally defined?C933103 (talk) 22:09, 30 August 2018 (UTC)[reply]

If the property is created, people will use it any way they like. It's quite possible that people not familiar with Wikidata will pick it instead of citizenship. Ghouston (talk) 04:28, 31 August 2018 (UTC)[reply]

Naming it something like legal nationality could help? C933103 (talk) 10:17, 31 August 2018 (UTC)[reply]

Pointing out that the "country of birth" is irrelevant to citizenship in many, many cases. E.g. millions of Palestinians have been born refugees in Jordan and Lebanon for decades but are stateless persons. They still have an ethnic group to which they belong (the Palestinian people) but no citizenship rights and certainly none in their countries of birth. —Justin (koavf)❤T☮C☺M☯ 00:08, 1 September 2018 (UTC)[reply]

I've seen somewhere recently the suggestion of using citizenships instead of countries in P27. So instead of P27 = United States of America, you'd have P27 = United States citizen. That would allow creating items for arbitrary citizenships and nationalities that aren't states, e.g., citizen of Puerto Rico or British National (Overseas) (Q5613380). That would be better than having separate properties for "country of citizenship" and "nationality". It would also allow describing citizenships better in their own right. E.g., Australian citizenship has an inception date of 26 January 1949. However, this still leaves the problem that people were commonly described as "Australian", even in the 19th century, and many are marked up that way in Wikidata. Ghouston (talk) 00:38, 1 September 2018 (UTC)[reply]

Additionally, American citizens are also citizens of states (for those who live in states--i.e. not D. C., Guam, CNMI, Puerto Rico, or USVI). —Justin (koavf)❤T☮C☺M☯ 01:10, 1 September 2018 (UTC)[reply]

It seems like a good idea. C933103 (talk) 04:34, 1 September 2018 (UTC)[reply]

I have always used both country of citizenship (P27) and ethnic group (P172) for people. That serves for all purposes. Let's take as examples revolutionaries for national independence:

⟨ Rigas Velestinlis (Q319684)  

 ⟩ country of citizenship (P27) ⟨ Ottoman Empire (Q12560)  

 ⟩

and

⟨ Rigas Velestinlis (Q319684)  

 ⟩ ethnic group (P172) ⟨ Greeks (Q539051)  

 ⟩

(he died before the creation of a nation-state called Greece). In many cases the most important property would be ethnic group (P172) (when someone looks for "German philosophers" usually looks for a list containing Immanuel Kant (Q9312) rather than ommiting most of those that would be included in such a list. -Geraki (talk) 18:28, 4 September 2018 (UTC)[reply]

Bulk edit/ remove labels

I created PIDapalooza 2019 (Q56373190) by duplicating PIDapalooza 2018 (Q47486859), and accidentally kept all the labels. Is there a tool that will remove all the labels from the former, or allow me to edit, at once, all those which say "PIDapalooza 2018" to say "PIDapalooza 2019"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:00, 30 August 2018 (UTC)[reply]

Put

mw.loader.load( '//www.wikidata.org/w/index.php?title=MediaWiki:Gadget-dataDrainer.js&action=raw&ctype=text/javascript', 'text/javascript' ); // [[MediaWiki:Gadget-dataDrainer.js]]

to Special:MyPage/common.js, and there will be a new dialogue linked from the “More” tab next to the search field. (Not sure why I can’t find it in the gadgets section of the preferences.) —MisterSynergy (talk) 14:15, 30 August 2018 (UTC)[reply]

That's just what I needed; thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:21, 30 August 2018 (UTC)[reply]

How to mark or report items which seem to be the same?

A colleague who is currently working on a mapping between STW Thesaurus for Economics (Q26903352) and Wikidata sometimes finds more than one counterpart for a STW descriptor. In obvious cases, he merges the items and goes on. In other cases, items cannot be merged, because they are linked to different Wikipedia pages, or a deeper understandig of the concepts would require more language knowledge - or the items look just too large and complex. One such case is the cluster of fishing (Q14373), fishery (Q180538) and commercial fishing (Q11202642). Please understand that we do not want to discuss this particular example here, but introduce it merely as an illustration of the problem. More generally, it is out of scope of the mapping work he is charged with, to solve such conflicts or invest time into a discussion about a proper solution.

What we could and happily would do is to mark such clusters we come across, in order to hint other users interested a the particular item to other items which seem to be the same. I've experimentally marked the three items mentioned above with said to be the same as (P460) inter each other. I'm not sure, if this is the right way (at that point, the dispute is only in our heads, and we don't want to make it explicit with arguments and counter-arguments). If somebody can point out a better practice of marking the involved items, which does not require much more work, or where to report such items on a maintenance page, we are happy to follow suit. We can also deal with the issues completely on our side of the mapping, but feel that would mean wasting insights we gained along the way. Jneubert (talk) 14:09, 30 August 2018 (UTC)[reply]

@Jneubert: "Said to be the same as" is not the correct sollution; a fishery (a venue) is not the same as "fishing" (an activity). In your example, "commercial fishing" is a subclass (or subcategory, if that helps) of "fishing" (which can be commercial or not). It would seem that you and your colleague need to be clearer about what precisely the thesaurus is, in such cases, describing. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:26, 30 August 2018 (UTC)[reply]

Does the STW contain a mapping between German and English? – Looking at your example, it is impossible to do a mapping de:STW = en:STW = en:WD = de:WD. Assuming that the STW mapping en:STW = de:STW is correct and that you will be able to do the mapping en:STW = en:WD with reasonable reliability, I would suggest that you focus on mapping en:STW = en:WD and output a maintenance list of all the cases where de:STW != de:WD. – Does that make sense?

I don't like the idea of using said to be the same as (P460) in this case. The problem here lies not so much in the fact that someone would claim that the concepts are the same, but more in fuzzy language links between different Wikipedias, in bad translations on Wikidata, etc.

--Beat Estermann (talk) 14:31, 30 August 2018 (UTC)[reply]

Thanks, Andy, Beat. The example was chosen because it is complex (the class and English description for fishing (Q14373) says it is an activity, but the German description says it is an economic sector) - this cannot be solved "en passant" in a straightforward way. The STW is concept-based (according to SKOS and ISO-25964), which means that the English and German labels should denominate exactly the same "unit of thought" (which, in the example, comprises the economic sector and the activities within that sector). It might be broken in some places, but it's the basic principle, and will do our best to fix errors (e.g., misleading labels or scope notes). For Wikidata, in my understanding the basic idea (one concept/item, multiple labels and descriptions in different languages) is the same, but due to historic reasons (Beat mentioned some) there are more places to fix things. In the mapping, we can take into account that Wikidata items may be ambiguous (e.g., by using a close match (Q39893184) mapping relation type (P4390), but we cannot fix more complex issues in Wikidata itself.

We can avoid said to be the same as (P460) - but is there another, more proper way to mark or report such clusters with seemingly overlapping items? Jneubert (talk) 15:28, 30 August 2018 (UTC)[reply]

Let me guess: Your dictionary entry refers to fishing industry (Q635139), as in "agriculture, fisheries, and forestry" / "Landwirtschaft, Fischerei und Forstwirtschaft". – You may have missed a WD entry. If this is the case, you should re-think your matching approach (in this case, if you match against "Fischerei" you'll get a false positive because the corresponding Wikipedia articles in German and English are not attached to the same WD item). --Beat Estermann (talk) 14:44, 30 August 2018 (UTC)[reply]

Thanks, obviously we indeed missed that one - which just adds to the complexity of the cluster. Jneubert (talk) 15:37, 30 August 2018 (UTC)[reply]

I think people are getting hung up here on what turns out to be a bad example, because in this case the answer would be, "Yes, there is a reason for all of these items to be distinct." The original question was how to mark things when there are doubts. - Jmabel (talk) 15:25, 30 August 2018 (UTC)[reply]

I don't think it is a bad example, because the various terms and definitions across languages are indeed a big mess in this case (if you were to match against the German version you would need to link to a different Q-number). Maybe you could give us a couple of further examples we can analyse in order to see whether the approach I suggested above would work for all of them. If you don't mind linking against messy data, you could just pretend that English is Wikidata's main language and ignore the other labels, outputting a list of problematic cases for the rest of the community to work on at a later point in time. If you're interested in linking against clean data, I would suggest that you invest some time in cleaning the data up before adding the STW identifiers. Having a list of problematic cases ready may help you mobilize some further helpers from the community. Linking a shitload of external identifiers (you are not the only ones) against messy data does not make much sense after all. By the way, what other data are you adding to the WD items apart from the STW identifiers? And do you have any specific use cases in mind for which your data ingest could be useful? (this could also be a good starting point for any reflections about the importance of having clean data in Wikidata in the first place.) --Beat Estermann (talk) 20:23, 30 August 2018 (UTC)[reply]

My colleague came across several such clusters of mostly rather high-level items with multiple language links. I hesitate to introduce them into this discussion, because we're not looking for a solution of the particular issues.

On the gereral level - if I didn't get you wrong - you suggested above to link in respect to language-specific labels/terms, and keep a maintenace list for exceptions. For the latter, we are currently implementing a mechanism. But that still is intended to work on a concept level, across all languages, with the main purpose of being able to provide users with more links to Wikipedia on STW pages (example). We at that point have no resources to get involved into Wikidata clean-up before linking, but would just pragmatically from our side offer links to items and WP pages which seem useful.

Sometimes cleaning up Wikidata would not work, because the mess results from reality. I brought up a - for an economics library quite fundamental - case some time ago: business administration (Q2043282), business economics (Q24208053), and business studies (Q5001951) are closely related and to some extent interchangeable concepts. In that discussion, my concern was about a in my eyes misplaced sitelink to (insofar quite similar to the above example). I was advised to take it to the talk page at the German Wikipedia (what I did), but without any response. What I also did - and what probably is of more lasting value - is interlinking the three according Englisch Wikipedia pages, which up to that point had been completely unrelated, with "See also" links, so readers and maintainers can at least easily discover the related pages.

Perhaps, a "see also" link could serve that purpose on Wikidata, too. There is related property (P1659), but this is restricted to properties. @Srittau: challenged that restriction on Property_talk:P1659, but without much response. So we're still stuck here. Jneubert (talk) 07:31, 31 August 2018 (UTC)[reply]

It seems just unlikely that someone on a Wikipedia talk will shed much light on this. At some point, one needs to determine what a Wikidata item is about and then, if some labels or sitelinks don't match that, move them to the appropriate items. Trying to fill up the Wikidata items with all subjects that might also be covered by one of the 256 Wikipedias is just not helpful.
--- Jura 18:28, 31 August 2018 (UTC)[reply]

@Pigsonthewing, Beat_Estermann, Jmabel, Jura1: Thank you for your contributions. I've removed the preliminary said to be the same as (P460) entries. Additionally, I did a bit of cleanup (moved de:Fischerei sitelink and adapted the German label of fishing (Q14373)). Since there currently seems to be no common way to mark such clusters of items, we will keep track of those which come up during the STW mapping process on our side. If we stick with the experimental publicly accessible exception list, that at least would allow others to trace dubious cases. Jneubert (talk) 16:28, 3 September 2018 (UTC)[reply]

Xantus's Murrelet, redux

I have once again restored the taxon name to Xantus’s murrelet (Q46338167), per past discussion at Wikidata:Project chat/Archive/2018/04#Xantus's Murrelet. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:45, 30 August 2018 (UTC)[reply]

Please have a look at the items talk page. --Succu (talk) 19:31, 30 August 2018 (UTC)[reply]

The "per past discussion" should be read as "per previous refusal to discuss". - Brya (talk) 05:21, 31 August 2018 (UTC)[reply]

Please watch this

Please add Project:Reference desk (Q3907025) to your watchlist, especially if you speak Spanish. The Spanish-language description has been changed to something irrelevant twice recently. I'm not sure how it's happening, but if it were on a few more watchlists, then perhaps these accidents would get reverted sooner. WhatamIdoing (talk) 15:41, 30 August 2018 (UTC)[reply]

Five times this year (plus reverts), all five times to complete nonsense.--Ymblanter (talk) 18:38, 30 August 2018 (UTC)[reply]

I've added it to my watchlist. Probably no need to protect at this point. -- Ajraddatz (talk) 19:11, 30 August 2018 (UTC)[reply]

That's my thinking, too, Ajraddatz. WhatamIdoing (talk) 21:33, 30 August 2018 (UTC)[reply]

How to mark a star belonging to an asterism (and vice versa)?

The Big Dipper (Q10460) is an asterism (Q9262) as well as a part of (P361) of Ursa Major (Q8918) which is a constellation (Q8928). There are seven stars that belong to the Big Dipper asterism, starting from Alpha Ursae Majoris (Q13084). Question: Should those stars be marked as being part of (P361) the Big Dipper, and, conversely, Big Dipper marked with "has part(s) (P527)" of those stars? Or should a new property, asterism, be created for those stars? That would be analogous to the current property "constellation (P59)" which, for all the Big Dipper stars, points to Ursa Major. However, a new property wouldn't explain what property, if any, to use at the asterism side of the relation. --ZeroOne (talk) 00:13, 31 August 2018 (UTC)[reply]

part of (P361) seems fine to me - I'm not convinced we need constellation (P59) in the first place, given the relatively small number of them, but I suppose there are plenty of stars they could apply to. But there aren't more than a handful or two of asterisms, are there? You can tell the child is a star, and the parent is whatever its instance of (P31) property says, so the meaning of part of (P361) should be perfectly clear. ArthurPSmith (talk) 13:50, 31 August 2018 (UTC)[reply]

OK, thanks for your input! I've now entered the Big Dipper stars as part of (P361) Big Dipper, and I also added the inverses, has part(s) (P527), for Big Dipper. I actually did this using the QuickStatements tool that I just learned about from your user profile, so thanks for sharing that information too! :) And yeah, Wikipedia only recognizes 25 asterisms, so a new property would seem like an overkill. --ZeroOne (talk) 19:35, 31 August 2018 (UTC)[reply]

Organizing template categories

We should decide how to deal with thousands of items (more than 37 thousands): please give your opinion here. Thank you! --Epìdosis 09:53, 31 August 2018 (UTC)[reply]

New user script: browser/desktop notifications for watchlist and recent changes

Hi all! I wanted to announce a useful user script I’ve written recently: User:Lucas Werkmeister/changeslist-notify.js translates live updates on your watchlist or recent changes into browser/desktop notifications. To use it, add the following line to your common.js (or even your global.js – it should work on any Wikimedia wiki):

mw.loader.load( '//www.wikidata.org/w/index.php?title=User:Lucas_Werkmeister/changeslist-notify.js&action=raw&ctype=text/javascript' );

Then, open a new tab with your watchlist or a recent changes page (e. g. lexeme changes), click the “live updates” button, and then just leave the tab open while you go about your business. If there’s an update, you should receive a notification within the next ten seconds. To disable the notifications on a particular page (e. g. on an unfiltered recent changes page, where updates are extremely frequent), press the “stop notifications” button right next to the “stop live updates” button (only visible when live updates are enabled).

Please keep in mind that while this means you may see new messages on talk pages more immediately than before, no one is entitled to an instant response by you, and there’s no such thing as “read receipts” on-wiki, so don’t feel pressured to react to notifications as fast as they come in. Personally, over the past few days I’ve found this user script very useful because it relieved me of the urge to constantly check my watchlist, but if you find that it stresses you out, please don’t use it! I’m sure this is not something for everyone, I just hope it will be useful for some people.

Disclaimer: this is a private project, done in my free time, independent of my work as Lucas Werkmeister (WMDE). --Lucas Werkmeister (talk) 12:42, 31 August 2018 (UTC)[reply]

Wikidata item popup preview does not work?

I put my mouse on an link to an wikidata item, but in the preview window, what it show is only https://i.imgur.com/UlIw6AJ.png . What's wrong with it?C933103 (talk) 04:32, 1 September 2018 (UTC)[reply]

Which gadget does this? Matěj Suchánek (talk) 10:01, 3 September 2018 (UTC)[reply]

Template:Property proposal content

Where is the boilerplate guidance text for {{Property proposal}} stored? I want to make (or propose) a change. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:35, 1 September 2018 (UTC)[reply]

Wikidata:Property proposal/Proposal preload? Template:Property proposal/doc? Matěj Suchánek (talk) 09:56, 3 September 2018 (UTC)[reply]

Two different Wikidata items referencing the same Wikipedia article

Prior to 2018-09-01 the Wikipedia article on "w:Historical Statistics of the United States" was a thinly veiled advertisement for the commercial version of this historical project that was introduced in 1949 by the US Census Bureau, then spun off to a commercial version after the 1975 edition. I added that 1975 edition to Wikidata as Q56424104 and then modified that Wikipedia article to also cite Q56424104.

However, I'm not allowed to link from Q56424104 to that Wikipedia article, because:

Could not save due to an error.

The save has failed.

The link enwiki:Historical Statistics of the United States is already used by item Q5773964. You may remove it from Q5773964 if it does not belong there or merge the items if they are about the exact same topic.

What do you suggest be done to resolve this conflict, if anything? I think it's appropriate for both Q56424104 and Q5773964 to reference this same Wikipedia article.

Wiktionary links for Hangul syllables/Unicode characters

Just a reminder that links to Wiktionary pages in the main namespace are disallowed on Wikidata. Please remove those which you have already added, whether to items about Hangul syllables or to other items, and do not add any more until that restriction is lifted, if that restriction is ever lifted someday. Mahir256 (talk) 19:30, 31 August 2018 (UTC)[reply]

@Mahir256: Thanks for the reminder. These statements have been removed. @Okkn: I think an exception should be made for Unicode characters to be linkable to Wiktionary pages. This could be discussed by the administrators. Wiktionary contains descriptive information and users may visit it for more information. KevinUp (talk) 19:48, 31 August 2018 (UTC)[reply]

@Mahir256: I understand we usually don't add sitelinks to Wiktionary pages in the main namespace, because they are not concepts, but is it really not allowed to add Wiktionary sitelinks? I think WD:N just says Wiktionary sitelinks are not valid to fulfill the notability criteria, but does not say we must not add Wiktionary pages to already created items, right? When it comes to Unicode characters, including Hangul syllable (Q55809450) and sinogram (Q53764738), they are clearly notable by themselves, and they are concepts rather than representation. Or if we add sitelinks to Wiktionary pages, the function of mw:Extension:Cognate does not work...? --Okkn (talk) 01:30, 1 September 2018 (UTC)[reply]

That makes sense. If links to Wiktionary pages are disallowed on Wikidata, then the input box that allows users to add Wiktionary links should be removed from Wikidata. KevinUp (talk) 05:09, 1 September 2018 (UTC)[reply]

The restriction only applies to Wiktionary pages in the main namespace, as I stated initially; links to categories/templates/Wiktionary: pages/etc. (except those in the citation, user, and all talk namespaces) are allowed. Mahir256 (talk) 21:15, 1 September 2018 (UTC)[reply]

This is a matter for the community at large to decide; not just administrators. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:43, 2 September 2018 (UTC)[reply]

Is it possible for us to take a vote regarding this matter? KevinUp (talk) 16:43, 2 September 2018 (UTC)[reply]

The discussion above was from my talk page. I wish to gain wider consensus regarding this matter. As mentioned by User:Okkn, Unicode characters such as Hangul syllable (Q55809450) and sinogram (Q53764738) are clearly notable by themselves, and are concepts rather than representation. Does this affect the function of mw:Extension:Cognate? KevinUp (talk) 08:18, 2 September 2018 (UTC)[reply]

Also, I have begun to link Unicode characters on Wiktionary to Wikidata. Wikidata is useful for obtaining structural data regarding Unicode characters while Wiktionary is useful for obtaining the meaning and usage of Unicode characters. KevinUp (talk) 08:18, 2 September 2018 (UTC)[reply]

WD:N state that the reason why wiktionary pages are excluded because wiktionary interlanguage links are done by Extension:Cognate with the reason on the extension page saying that the use of this extension is because wiktionary links are based on homograph, not concept. However, this assessment does not apply to each individual Unicode characters, since each individual Unicode characters are a concept in themselves, with many different data for each individual unicode code points. Especially for Pan-CJK characters. You can click into any wiktionary page about each individual CJK characters page and see how many values there that can be stored centrally, and there's even a non-WMF wiki known as glyphwiki that store even more info about individual CJK character codepoints. Because of such a number of data that can be centrally managed at wikidata, and because each Unicode code point are representing the same, single concept of a single Unicode code point instead of being merely homonym, I suggest changing the policy to allow the storage of those data within wikidata. C933103 (talk) 14:31, 2 September 2018 (UTC)[reply]

Well said indeed. Recently, Wikidata:WikiProject CJKV character has been created to provide structural data for the 88,889 CJKV characters available in Unicode 11.0. Prior to this, only a small number of Unicode items exist. For comparison, please compare 雨 (Q3595028) with wikt:雨. KevinUp (talk) 16:43, 2 September 2018 (UTC)[reply]

I believe the restriction was a request from the Wikidata developers, not something that community consensus can address. @Lea Lacroix (WMDE), Lydia Pintscher (WMDE): can you comment? ArthurPSmith (talk) 12:38, 4 September 2018 (UTC)[reply]

I would like to create a report on new articles: users, wordcount, categories, bytes for a specific wikiproject

I know that I can find out information about wikipedia articles (wikidata items) and their properties on Wikidata. I would like to find information on user contributions per month for a specific Wikiproject. This would help with wikiproject planning and management. I am not a developer. Can you point me in the right direction if Wikidata is not the place to get that info? thx MauraWen (talk) 15:49, 2 September 2018 (UTC)[reply]

@MauraWen: Wikidata does not carry metadata about user actions in other wikimedia projects; the data in Wikidata is about the concepts that are described in articles, not about the articles themselves. What you are looking for may be available however from the Wikimedia Statistics pages; please check there. ArthurPSmith (talk) 12:55, 4 September 2018 (UTC)[reply]

thx @ArthurPSmith: for answering my question. I eventually figured out that this is a metadata issue, but glad to hear Wikimedia statistics is the best place to get that information. MauraWen (talk) 13:10, 4 September 2018 (UTC)[reply]

What is the URL of the RDF representation a property?

Tracked in Phabricator
Task T203400

For example the property P279 (subclass of): https://www.wikidata.org/wiki/Property:P279

According to usage in other entities, it should be http://www.wikidata.org/prop/direct/P279

But there no RDF content obtained at this URL by content negotiation, only HTML is gotten:

wget --save-headers --header='Accept: text/turtle' http://www.wikidata.org/prop/direct/P279

or

wget --save-headers --header='Accept: application/rdf+xml' http://www.wikidata.org/prop/direct/P279
wget --save-headers --header='Accept: application/ld+json' http://www.wikidata.org/prop/direct/P279

My use case

I have a web tool that is completely generic about LOD data source , for example here is what I get from a Wikidata URI :

http://semantic-forms.cc:1952/search?q=http%3A%2F%2Fwww.wikidata.org%2Fentity%2FQ40044858

– The preceding unsigned comment was added by Jmvanel (talk • contribs) at 07:55, 3 September 2018‎ (UTC).[reply]

Thanks to Mister Synergy for the Special:EntityData URL's , that are documented at the right place in the doc. https://www.wikidata.org/wiki/Wikidata:Data_access#Linked_Data_interface . This answers to the original question in the title.

However, there is still an issue with respect to Semantic Web good practices. Namely, that an URI should be dereferentiable and subjected to RDF/XML, Turtle, and HTML content negotiation . This indeed is the case for URL's with prefix http://www.wikidata.org/entity/ . But properties, as they are used in triples, are not. For instance, this entity http://www.wikidata.org/entity/Q1656682 uses a property with URL http://www.wikidata.org/prop/direct/P279 . But this latter URL only provides HTML, as demonstrated above. Instead, this well behaved URL should be used in Wikidata RDF data: https://www.wikidata.org/wiki/Special:EntityData/P279 . It is probably the same with every property; prefix should be used https://www.wikidata.org/wiki/Special:EntityData/ . But it would be probably more coherent if http://www.wikidata.org/entity/P279 would be used. It is also a well behaved URL prefix.

Special:EntityData/P279.rdf (or as full URL https://www.wikidata.org/wiki/Special:EntityData/P279.rdf)
Special:EntityData/P279.nt (or as full URL https://www.wikidata.org/wiki/Special:EntityData/P279.nt)
Special:EntityData/P279.ttl (or as full URL https://www.wikidata.org/wiki/Special:EntityData/P279.ttl)

—MisterSynergy (talk) 09:04, 3 September 2018 (UTC)[reply]

The canonical URI for the property with ID P279 is just like the canonical URI for the item with ID Q42: http://www.wikidata.org/entity/P279, abbreviated wd:P279. wdt:P279 (…/prop/direct/P279) is just one of several predicates related to that property (there’s also /prop/, /prop/statement/, /prop/qualifier/value, etc.) – all of these predicates have different meanings, and we can’t just replace them all with the entity URI because that one happens to resolve better for certain use-cases. However, we can change the other URIs to be more well-behaved – I’ve filed phabricator:T203400 for this. --Lucas Werkmeister (WMDE) (talk) 14:33, 3 September 2018 (UTC)[reply]

Thanks for filing an issue, Lucas; since it's not clear to me , shall we continue discussion here or in phabricator:T203400 ? – The preceding unsigned comment was added by Jmvanel (talk • contribs) at 17:21, 3 September 2018‎ (UTC).[reply]

@Jmvanel: I guess it’s easier to do it here, if you have any more comments. --Lucas Werkmeister (WMDE) (talk) 10:34, 4 September 2018 (UTC)[reply]

P248 instead of P143

Hi, I noticed that a large number of items use stated in (P248) to cite Wikipedias, instead of using imported from Wikimedia project (P143) just to notice that the information comes from there (unnecessary IMO if there exists a valid source). Wikipedias are not considered valid sources: Help:Sources#Different_types_of_sources. It was noticed in Greek Wikipedia that in relevant articles these wikipedias are cited in the references section through automated infoboxes. I believe that a bot that will change all these stated in (P248)English Wikipedia (Q328) to imported from Wikimedia project (P143)English Wikipedia (Q328) would be of great value. -Geraki (talk) 13:01, 3 September 2018 (UTC)[reply]

There are a little more than 14.000 of such references (query1, query2). I can fix them later this day. —MisterSynergy (talk) 13:17, 3 September 2018 (UTC)[reply]

All done now. The final ~200 cases where cluttered so much that I had to repair them manually after the bot did most of the work :-/ —MisterSynergy (talk) 22:54, 3 September 2018 (UTC)[reply]

It would be nice to make this a constraint violation for stated in (P248) P.a.a (talk) 15:59, 3 September 2018 (UTC)[reply]

As I understand it, "stated in" is correct for manual addition of an entry, "imported from" when scraped by a bot. Is that not correct? - Jmabel (talk) 16:20, 3 September 2018 (UTC)[reply]
- No, this is not correct (although the English description of imported from Wikimedia project (P143) might indicate it). Wikipedias typically discard imported from Wikimedia project (P143) references as “not considered valid sources” (as indicated above), and consider stated in (P248) references to be always serious. It does not matter whether the referenced value was added by hand or bot. You can thus import from Wikipedia by hand, and indicate it with imported from Wikimedia project (P143) in the reference. —MisterSynergy (talk) 16:46, 3 September 2018 (UTC)[reply]
  - And the Spanish says the same as the English, and both are rather specific and prescriptive about it. If it is wrong, them someone should certainly change it. - Jmabel (talk) 19:43, 3 September 2018 (UTC)[reply]
    - English description is changed; someone proficient in Spanish could do the same for the other label. —MisterSynergy (talk) 22:54, 3 September 2018 (UTC)[reply]

Good work MisterSynergy! Thanks. -Geraki (talk) 16:36, 4 September 2018 (UTC)[reply]

Item merger

Hi,

I think I spoted two idems which should be merged, but don't know how to do it. I'm basing this on the fact that the Wikipedia pages are about the same topic. I assume that it got fragmated at some point.

If someone could smush these two togeter it would be helpful. Thanks.

--2A00:EE2:204:7500:D461:77CF:8760:7131 19:40, 3 September 2018 (UTC)[reply]

See Wikidata:Merge. But I believe you will have to log in to do this. - Jmabel (talk) 19:47, 3 September 2018 (UTC)[reply]
- There are also sitelink conflicts and both seems to describe a different concept. Sjoerd de Bruin (talk) 20:07, 3 September 2018 (UTC)[reply]

Is it possible to add ebird data to Wikidata?

Hello everyone, eBird is a website by Cornell Lab of Ornithology. eBird has a lot of data about birds. If we can able to add them to Wikidata it would be a great achievement for the birders. Because through query service we can find exactly how many number of birds found (from eBird checklist) in this area in so and so the duration of time. I had shared this with Ijon. He suggested me to write here and ping Pigsonthewing. Let me know if it is possible. I can write to contact Cornell Lab also. --Gopala Krishna A (talk) 03:56, 4 September 2018 (UTC)[reply]

Note we have eBird taxon ID (P3444) and eBird hotspot ID (P5200) which can link wikidata items to the eBird website (and about 13,000 taxa have already been linked). Pulling in all their data is beyond the scope of Wikidata; it may also not be legally allowable - I couldn't find a rights statement on the eBird site, but Wikidata data is CC-0 so the licensing would need to be compatible. I'm also not sure the data structure of this site is right for this kind of information - you would presumably have to create a statement on each bird item for every observation (with location, date, count)? This might be something that could be done via tabular data in Commons however. ArthurPSmith (talk) 13:10, 4 September 2018 (UTC)[reply]

Further to Arthur's very good reply; there's not much point in us trying to replicate what eBird do. In time, it's to be hoped that services like eBird will see the value in making their data available as linked-, open-, data, and providing a SPARQL end-point, so that people can make federated (combined) queries across their database and ours. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:41, 4 September 2018 (UTC)[reply]

Thanks everyone for your valuable time and reply. I would also recommend eBird to start a SPRQL based query search on their website. --Gopala Krishna A (talk) 08:03, 5 September 2018 (UTC)[reply]

Wikidata weekly summary #328

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

Events
- 3-5 September, Bologna: Workshop on Open Citations, with several WikiCite-related talks and an associated hackathon
- 8 September, Zurich, Switzerland: Wikidata Hackathon
- September and early October: Andy Mabbett is touring Australia for a series of open-science and GLAM Wiki-focused talks, workshops, and meetups.
- 23 October 2018, Berlin: Workshop How can I use Wikidata for my research?
- Applications are invited for WikiCite 2018 (27-29 November in Berkeley)
- Registration is now open for PIDapalooza 2019 in Dublin, Ireland on 23-24 January.

Press, articles, blog posts
- Many faces of Wikibase: Cataloging the history of the Illuminati

Other Noteworthy Stuff
- New admin: Abián. Welcome onboard!
- Better suggestions for constraint values on properties
- Wikidata now has 100 million qualifiers on statements
- A proposal comes forth to use Wikidata Qs as permanent IDs for OpenStreetMap. See the discussion.
- A Stanford University announces a Wikimedian in Residence position focused on Library metadata and Wikidata: see the announcement on Wikidata-l
- SourceMD and ORCIDator have been merged and can now be run in batch mode (announcement by Magnus Manske)

Did you know?

Development
- Final polishing on first version of Senses support for Lexemes. (phabricator:T201000, phabricator:T202729, phabricator:T198036, phabricator:T203334)
- Continued work on merging Lexemes. Merging via the SpecialPage is done and will be rolled out soon. Merging via the API is still being worked on. (phabricator:T189129)
- Long Lemmas in Lexemes look bad because they are not flowing to the next line and instead break the layout. Working on a fix. (phabricator:T195367)
- Improving the validity of the HTML of the Lexeme headers. (phabricator:T196228)
- Worked on showing the Lemma(s) or Representation(s) when Lexemes or Forms are mentioned in constraint reports. (phabricator:T195315)
- Got a new beta feature ready for deployment that will improve the suggestions for properties like sex/gender by first suggesting the values defined in the one-of constraint. (phabricator:T202712)

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) 08:15, 4 September 2018 (UTC)[reply]

Starting Wikidata Query Library

Yes we have Query Examples but it is a very good idea to start a Portal or Libaray that store all kind of queries sorted by subject, Category etc.. and Featured query, Start your first query, New queries, Request for a query etc.. Can we do a query contest? --Ranjithsiji (talk) 10:29, 4 September 2018 (UTC)[reply]

There's a parallel discussion on Facebook, where a Query: namespace has been proposed, with one query per page, using Wikipedia- (or Commons-) style categories to aid findability. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:59, 4 September 2018 (UTC)[reply]

Not sure if this has been raised elsewhere, but a "Query" namespace has been part of Wikidata for a long time - but it's unused because the original approach to querying was abandoned in favor of the SPARQL service we have now. See this page for some details and links; you can also see a trace of the Query namespace when you do an advanced search, it's one of the options (but there's nothing there). ArthurPSmith (talk) 17:50, 4 September 2018 (UTC)[reply]

Do you speak German/French? Help WLM 2018 Switzerland!

Hello guys!

Do you see these giant "de" and "fr" bubbles? If you understand German/French, you can be very useful in helping Wiki Loves Monuments in Switzerland in translating as monuments as possible in English. We want to see the "en" bubble growing!

Here the list of the monuments that need an English label
- Only from German
- Only from French

Even providing an English label to just 2-3 monuments will be very appreciated... but pay attention: it's a drug! :^) Thanks you everybody and have fun! --Valerio Bozzolan (talk) 15:16, 4 September 2018 (UTC)[reply]

Sourced invalid statements

I have seen many cases like this: https://www.wikidata.org/wiki/Q384813#P131

⟨ Temple of Athena Nike (Q384813)  

 ⟩ located in the administrative territorial entity (P131) ⟨ Acropolis of Athens (Q131013)  

 ⟩

Obviously Acropolis of Athens (Q131013) is not an administrative unit. But there is a reference for this statement, although not an authoritative one: https://www.archinform.net/projekte/3921.htm . In fact even the source does not support the claim, it lists the Acropolis as "sonstige Fläche" (to my understanding it means "other"?) Another example would be the statement that an uninhabited islet is a "settlement" just because it is included in census records with 0 population (in fact that would be proof that it is not a settlement). What do you think about the removal of sourced statements that contradict themselves, other sources or common sense? -Geraki (talk) 17:05, 4 September 2018 (UTC)[reply]

In your Temple of Athena Nike (Q384813) example, clearly someone picked the wrong property: the relationship is basically right, but it should use location (P276) rather than located in the administrative territorial entity (P131). - Jmabel (talk) 02:12, 5 September 2018 (UTC)[reply]

I guess the statement with P131 should be

⟨ Temple of Athena Nike (Q384813)  

 ⟩ located in the administrative territorial entity (P131) ⟨ Acropolis (neighborhood) (Q2336187)  

 ⟩

. Xaris333 (talk) 09:53, 5 September 2018 (UTC)[reply]

About the 0 population: if an administrative territorial entity has 0 popolulation, is not a problem. The administrative territorial entity is still exist as a legal entity, even thought no one is living there at the moment. Xaris333 (talk) 09:52, 5 September 2018 (UTC)[reply]

contains administrative territorial entity: value type constraint

Hello. Limassol Municipality (Q28870916) -> contains the administrative territorial entity (P150). It shows value-type constraint (Q21510865). Before some time, there was not such problem. I guess something changed with the value of a property of Quarter of Limassol Municipality (Q29463880). Like third-level administrative division (Q13221722) or third-level administrative division (Q13221722) or about an item which those two are subclass. Because I have created many items for third-level administrative country subdivision for Cyprus, I want to know what to do, so the structure will be correct. Xaris333 (talk) 09:47, 5 September 2018 (UTC)[reply]

If what you are writing is correct, it should be subclass, not an instance. Fixed that > works now. --- Jura 11:08, 5 September 2018 (UTC)[reply]

@Jura1: thanks. But how can I connect Quarter of Limassol Municipality (Q29463880) with Limassol Municipality (Q28870916)? I did it with located in the administrative territorial entity (P131) but I get item-requires-statement constraint (Q21503247). Xaris333 (talk) 11:31, 5 September 2018 (UTC)[reply]

Maybe the "designation"-P31 should be used there .. Also, I don't think P131 should be used for that. I changed it to "part of". --- Jura 11:35, 5 September 2018 (UTC)[reply]

Ok for part of, but I don't think P31 -> administrative territorial entity type (Q15617994) is correct. Xaris333 (talk) 12:34, 5 September 2018 (UTC)[reply]

Make Wikidata P and Q templates universal in Wikimedia projects

I am writing to propose making P and Q templates in Wikimedia projects outside Wikidata, in every language, to redirect to Wikidata. Any comment here in support or criticism of this idea will help future planning.

Is anyone aware of this being discussed before? Can anyone say where they saw this, even if it was another language or project?

Consider {{P}} and {{Q}}. In Wikidata these templates are fundamental to quick discussion of Wikidata items and properties because they convert Wikidata identifiers to human readable text for conversations. Outside of Wikidata in other Wikimedia projects there are often P and Q templates which link to Wikidata. For example, see Commons:Template:P and Commons:Template:Q. Having these templates in place means that irrespective of language or project, editors can use P and Q templates to make connections to Wikidata.

Check out Template:Wikidata property link (Q19694638) and Template:Wikidata entity link (Q17280715), which are Wikidata's own records of which Wikimedia projects have equivalent templates by any name. Each of these are currently in about 40 Wikimedia projects. In about 20 cases the name is P or Q. In other cases perhaps there is another name, but P and Q are redirects. For some of the cases P and Q go to non-Wikidata uses. I think there are about 800 Wikimedia projects total. If it would be useful to make P and Q templates universal then we should make some plan to set that up or reserve it.

In English Wikipedia en:Template:P currently goes to en:Template:Smiley to make an emoji. In German it goes to en:Template:P for "priority" or the number 1. In French fr:template:P goes to the portal system. It causes big social problems to change templates which get established in Wikimedia community projects. Wherever possible we should propagate templates out now so that in the future we do not have to negotiate for this in every language and every project. Currently I am talking about this on English Wikipedia at en:Template talk:P where there is resistance to the idea.

Sorry - I have a major deficiency in this, in that I do not know the best way to migrate templates across languages and projects. If anyone can point to documentation on how to do this or outline the workflow of how this should go down then speak up. Also, if anyone has an objection to making P and Q templates universal then please say why. Blue Rasberry (talk) 14:04, 5 September 2018 (UTC)[reply]

@@ Line 693: / Line 693: @@
 Ok for part of, but I don't think P31 -> {{Q|15617994}} is correct. [[User:Xaris333|Xaris333]] ([[User talk:Xaris333|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 12:34, 5 September 2018 (UTC)
+== Make Wikidata P and Q templates universal in Wikimedia projects ==
+I am writing to propose making P and Q templates in Wikimedia projects outside Wikidata, in every language, to redirect to Wikidata. Any comment here in support or criticism of this idea will help future planning.
+Is anyone aware of this being discussed before? Can anyone say where they saw this, even if it was another language or project?
+Consider {{tl|P}} and {{tl|Q}}. In Wikidata these templates are fundamental to quick discussion of Wikidata items and properties because they convert Wikidata identifiers to human readable text for conversations. Outside of Wikidata in other Wikimedia projects there are often P and Q templates which link to Wikidata. For example, see [[Commons:Template:P]] and [[Commons:Template:Q]]. Having these templates in place means that irrespective of language or project, editors can use P and Q templates to make connections to Wikidata.
+Check out {{Q|19694638}} and {{Q|17280715}}, which are Wikidata's own records of which Wikimedia projects have equivalent templates by any name. Each of these are currently in about 40 Wikimedia projects. In about 20 cases the name is P or Q. In other cases perhaps there is another name, but P and Q are redirects. For some of the cases P and Q go to non-Wikidata uses. I think there are about 800 Wikimedia projects total. If it would be useful to make P and Q templates universal then we should make some plan to set that up or reserve it.
+In English Wikipedia [[:en:Template:P]] currently goes to [[:en:Template:Smiley]] to make an emoji. In German it goes to [[:en:Template:P]] for "priority" or the number 1. In French [[:fr:template:P]] goes to the portal system. It causes big social problems to change templates which get established in Wikimedia community projects. Wherever possible we should propagate templates out now so that in the future we do not have to negotiate for this in every language and every project. Currently I am talking about this on English Wikipedia at [[:en:Template talk:P]] where there is resistance to the idea.
+Sorry - I have a major deficiency in this, in that I do not know the best way to migrate templates across languages and projects. If anyone can point to documentation on how to do this or outline the workflow of how this should go down then speak up. Also, if anyone has an objection to making P and Q templates universal then please say why. [[User:Bluerasberry|<span style="background:#cedff2;color:#11e">''' Blue Rasberry '''</span>]][[User talk:Bluerasberry|<span style="cursor:help"><span style="background:#cedff2;color:#11e">(talk)</span></span>]] 14:04, 5 September 2018 (UTC)

Wikidata:Project chat: Difference between revisions

Revision as of 14:04, 5 September 2018

Inconsistent constraints for father (P22) and mother (P25)

Denisova 11

Link to commons wiki and conflict between gallery and category

Moveable dates

Song and clip, one or two items?

Q56222412

Fixing the search to be useful again; aka making the simple, simple again

Category:Swedish words prefixed with ytter-

Merge instructions - where?

several job openings in or around the Wikidata dev team

Implementation of a new Wikidata-to-OSM service for P402

Duplicate creation by GZWDer_(flood)

Question about mass adding properties into wikidata

Puerto Rican nationality

Equivalent to e.g Property:GND for Wikidata Object IDs?

Splitting country of citizenship (P27)

Bulk edit/ remove labels

How to mark or report items which seem to be the same?

Xantus's Murrelet, redux

Please watch this

How to mark a star belonging to an asterism (and vice versa)?

Organizing template categories

New user script: browser/desktop notifications for watchlist and recent changes

Wikidata item popup preview does not work?

Template:Property proposal content

Two different Wikidata items referencing the same Wikipedia article

Other questions

Wiktionary links for Hangul syllables/Unicode characters

I would like to create a report on new articles: users, wordcount, categories, bytes for a specific wikiproject

What is the URL of the RDF representation a property?

P248 instead of P143

Item merger

Is it possible to add ebird data to Wikidata?

Wikidata weekly summary #328

Starting Wikidata Query Library

Do you speak German/French? Help WLM 2018 Switzerland!

Sourced invalid statements

contains administrative territorial entity: value type constraint

Make Wikidata P and Q templates universal in Wikimedia projects

Navigation menu

Search