User talk:MisterSynergy

Jump to: navigation, search

About this board

Edit description
Babel user information
de-N Dieser Benutzer spricht Deutsch als Muttersprache.
en-4 This user has near native speaker knowledge of English.
Users by language

Previous discussion was archived at User talk:MisterSynergy/Archive 1 on 2015-11-09.

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL
VIGNERON (talkcontribs)

Hi,

I just realized that I don't know how to specify references with the template {{Claim}} and the documentation of the template doesn't seem to show how to do it.

Could you tell me?

MisterSynergy (talkcontribs)

Hi VIGNERON

Frankly, I don’t know either. I just realized that you talked about references, but used a claim template.

Interesting to read in this context: Wikidata:Glossary#Claims and statements. TL;DR: Claim = Value + (optional) Qualifier, whereas Statement = Claim + (optional) Source + (optional) Rank. I would thus not be surprised if the {{Claim}} template didn’t support references at all…

Reply to "Template claim and references"
Jura1 (talkcontribs)

Please note User_talk:WikiDataMovieDB#Property_talk_pages

MisterSynergy (talkcontribs)

Thanks. I guess you particularly want me to take notice of the third bullet point? I can’t reproduce what’s claimed there — where do I have to look at?

Jura1 (talkcontribs)

The first and the third.

It can't be reproduced immediately as constraint definitions are only reloaded every couple of months.

MisterSynergy (talkcontribs)

On #1) I did not add any country-related templates; I just shifted them around a bit, when necessary. Actually I don’t really care whether they are there or not, they just should not be in the wrong place.

On #3) Property talk:P2091 has section headers immediately before the constraint boxes since August 3, 2016 [diff]. Yet the constraints appear on Special:ConstraintReport/P2091 about the property itself as well as on items which use the property, such as Special:ConstraintReport/Q576663. How long does this flaw take to become effective, if it still works after 9 months?

MisterSynergy (talkcontribs)

I assume that this problem has been solved meanwhile and proceed with further section headers. If you observe that the flaw is still effective, please let me know. I’d immediately open a bug report via Phabricator in that case.

Jura1 (talkcontribs)

I don't think it has been resolved. Please stop adding them.

MisterSynergy (talkcontribs)

We basically talk about a bug here, which needs to be solved anyway. In no way it is a reason not to structure property talk pages.

Special:ConstraintsReport is broken in many regards anyway. A significant number of checks is not properly implemented, there is an unquantifiable lag in data recognition, it produces cryptic hints and wrong/useless links when violations are found, it can’t properly deal with item redirects, and it basically relies on the property talk page templates, which might change as well in future. This page is not functional at all at the moment, regardless of the problem you claimed here.

Since I nevertheless like this functionality a lot, I am using Javascript to add a link to the left naviation panel on all Property and Item pages for convenient access to Special:ConstraintReport. In February I also asked the developers to put effort into this promising Special: page, but unfortunately they have not done so obviously.

Jura1 (talkcontribs)

Well, there is a bug and it's unlikely to be resolved. In any case, once it's resolved the templates will be redundant. So please stop breaking things in the meantime.

Currently you can use the bug to disable unhelpful error messages, e.g. the single value constraint for VIAF on Special:ConstraintReport/Q21329086.

MisterSynergy (talkcontribs)

Helpful example, thanks.

However, I am not sure whether this is caused by the existence of section headers, or by the fact that constraint reports are basically split into different block – which typically isn’t the case. I’ll keep an eye on that an eventually report it to the developers.

Jura1 (talkcontribs)

There seem to be working on some of the GUI stuff (see the new script) and became aware that the actual message displayed to users might need different wordings depending on the constraints.

BTW, you might want to have a look at Property talk:P369 which tests a replacement for constraint templates.

MisterSynergy (talkcontribs)
  1. Uhm, what’s “the new script” all the people are talking about recently? I haven’t noticed any differences.
  2. I am browsing phabricator right now and there is indeed something going on in the field of constraint checks, but it does not appear to be necessarily related to Special:ConstraintReport.
  3. Thanks for the link to the sandbox property.
MisterSynergy (talkcontribs)

I guess I found “the new script” here: Wikidata:Project chat#Script and API module for constraint checks.

This comment was hidden by Jura1 (history)
Jura1 (talkcontribs)

yes.

Reply to "Property talk page format"
IKhitron (talkcontribs)

Hi. Could you leave it, please? We really need it in our wikipedia, and it's not wrong. Please?

MisterSynergy (talkcontribs)

Hey IKhitron, that was not clear to me. What’s the purpose of this claim? Generally different from (P1889) is meant to be used on items which are often confused. I don’t see any potential to confuse something here, but I might me wrong…

Do you maybe look for another property instead? Thanks for your comment, and regards!

IKhitron (talkcontribs)

Hi. The problem is that we have a tracking category for the articles that need to be added a gender field in wikidata. We try to keep it empty. So it should not include articles that have no need in gender. The code I wrote checks this property for this purpose, and excludes the article. There are about five articles where I added this property. Please?

MisterSynergy (talkcontribs)

Wojtek (Q1055802) and American Idol (Q201052) are the only others.

different from (P1889) was not made to serve that purpose, that’s why it is not surprising that your claims are being removed. Could you implement a different approach in which your template/module checks whether P31:Q5 is there, and if not, then exclude it from the required gender tracking category? This would be much more robust in the long run…

IKhitron (talkcontribs)

The problem is it should work nevertheless there is already p31:q5. Almost always it isn't. Does it disturb to somebody?

And it's also Russian Military Police (Q2895987), Murder of Avi Sasportas and Ilan Saadon (Q11120414), Murder of Oleg Shaichat (Q4166672).

MisterSynergy (talkcontribs)

In some sense: yes it does, that’s why I’m suggesting to improve the claims. different from (P1889) is a symmetric property, which means is should be used on both items of the pair to differentiate them. It would be impossible to add all these claims to human (Q5) just because of internal reasons. (Btw. the other listed items do not have P1889:Q5 set right now.)

Humans should be tagged by P31:Q5 anyway. There are methods to do this, e.g. by comparing human-only categories with Wikidata with the Petscan-Tool. It is then easy to batch-process all items which still lack P31:Q5 with Petscan as well, and then you can start to look for P21 as well.

Would you mind showing me the template/module code at hewiki? I already found the tracking category, but I did not find the code in question.

IKhitron (talkcontribs)

I know about other methods, but we think categories is much better, for the work and psychologically.

It's w:he:template:לפי מגדר/בדוק

IKhitron (talkcontribs)

NB: Of course, phab:T60954 is ways better. But it's still open.

MisterSynergy (talkcontribs)

Yep, very annoying. We still have to purge or nulledit pages and/or categories to see the actual categorization. I’d not expect to have this solved in the near future, but I’d be happy if they changed it.

IKhitron (talkcontribs)

I talked about about a boolean query {#isincategory:categoryname|pagename}.

MisterSynergy (talkcontribs)

Okay, it is almost fully hebrew and used in many templates and pages. I am not going to touch it :-)

I understand the desire to have tracking categories to maintain associated Wikidata items. But I am still not convinced that this is the only way you can achieve that. This tracking category has three subcategories:

  • not connected to Wikidata (empty right now)
  • P21 missing for humans (56 elements)
  • and P21 “missing”, but not actually a person (13 elements)

You can easily add another tracking category such as “P31 missing” in cases where there is no P31 at all in the connected Wikidata item. If P31 is there, you can decide whether to put it to the human category (if P31:Q5) or to the other one (P31:not Q5). Right?

IKhitron (talkcontribs)

Yap. But I don't want to decide. I want the code decide it automatically. And I REALLY don't want to create a whitelist as a huge #switch.

MisterSynergy (talkcontribs)

The code should and can decide without a switch. Flowchart in pseudo code:

if (article is connected to Wikidata) {

--> if (Wikidata item has any P31 claim) {

--> --> if (Wikidata item has P31:Q5) {

--> --> --> if (Wikidata item does not have P21) {

--> --> --> --> add to category:"human needs P21 at Wikidata" (56 elements at the moment)

--> --> --> } else {

--> --> --> --> do nothing, since no action is required

--> --> --> }

--> -->} else {

--> --> --> do nothing, since no action is required, or add to category:“no P21 at Wikidata, but nothing to do” (the 13 elements category)

--> -->}

--> } else{

--> --> add to category:"Wikidata item does not have any P31 claim" (does not exist right now)

--> }

} else {

--> add to category:"article without Wikidata item" (empty right now)

}

IKhitron (talkcontribs)

What do you mean in "do nothing, since no action is required, or add to category:“no P21 at Wikidata, but nothing to do” (the 13 elements category)"?

MisterSynergy (talkcontribs)

https://he.wikipedia.org/wiki/%D7%A7%D7%98%D7%92%D7%95%D7%A8%D7%99%D7%94:%D7%A7%D7%91%D7%95%D7%A6%D7%95%D7%AA_%D7%97%D7%A1%D7%A8%D7%99_%D7%9E%D7%92%D7%93%D7%A8_%D7%91%D7%95%D7%95%D7%99%D7%A7%D7%99%D7%A0%D7%AA%D7%95%D7%A0%D7%99%D7%9D (sorry, don’t know how to properly use an internal link here)

All elements of that category don’t need a P21 claim, but the category does not do anything else than to say that there is no P21 (if I understand correctly). Thus, an editor can do nothing to fix this “problem” and the categorization can be omitted.

(All assuming I get the scope of this category correctly using Google Translate.)

IKhitron (talkcontribs)

Sorry. I still do not understand you at all. How does the code recognizes, for something without P21 and P31, if it is a person that needs P31 or not a person at all? There are no other diffences, just that one you want me to remove.

MisterSynergy (talkcontribs)

The proposed category:"Wikidata item does not have any P31 claim" does not care about whether it is an article about a human or not. Almost all items at Wikidata need a P31, so if there is none, the article can be put into a such a category.

Once the item has P31 (either with or without Q5), one could continue and suggest to add P21 via tracking categories, if P31:Q5.

IKhitron (talkcontribs)

Maybe I'm really stupid. But I can't understand you. Let's try again. There are two articles, A and B. A is not a person, but it falls under the characteristic "should be checked". As not person, it have no P21 and P31:Q5. B is a person that still not have P21 and P31:Q5. Will they be in the same category?

MisterSynergy (talkcontribs)

You’re definitely not stupid. Not at all.

Yes, both articles would be in the same tracking category. The purpose of this tracking category would be that users can browse through the elements and decide that A is not a person (by adding at Wikidata P31:any value other than Q5) and that B is a person (by adding P31:Q5 at Wikidata). The template/module then recognizes the changed situation and automatically re-categorizes the article into the tracking category "P21 missing at Wikidata" – for the human articles only. The other ones (not humans) will not appear any longer in any tracking category, and you particularly do not need a marker “not a person” at Wikidata, which different from (P1889) human (Q5) in fact is.

IKhitron (talkcontribs)

Well, I unserstand you now. Do you mean P31 can have only one value any time?

MisterSynergy (talkcontribs)

P31 can have multiple values, but this is a rare situation. The presence of a P31:Q5 claim makes the item describing a human. The absence of P31:Q5 means either the opposite (not a human) or that this claim has not yet been added. It is extremely rare that an item about a human has already a P31 claim, but not with Q5 as value.

IKhitron (talkcontribs)

So, A and not-yet-classified will be in the same category?

MisterSynergy (talkcontribs)

“A” will leave the category once it has a P31 claim, no matter whether it is Q5 or not. There are only “not-yet-classified” articles in this category (humans and non-humans).

IKhitron (talkcontribs)

I see. Let me think about that a couple of days. I'll be back. Thanks.

MisterSynergy (talkcontribs)

No problem. Feel free to ask me again in case of questions – I’d be happy if I can help. Regards!

IKhitron (talkcontribs)

Thank you again.

IKhitron (talkcontribs)

Hi. Remember me? Sorry, I has no time until today. Now I checked this, created in Excel a 128-lines table for all possible combinations, and made it only 24 for the relevant ones. Here are the results:

I think there should be a difference in the code you proposed, to catch much more cases: If the item has P21 and does not have P31:Q5, it should go to a new tracking category, that should be regularly emptied.

This way we catch 20 cases from 24.

2 more cases are not our problem, it's Wikidata vandalism - not persons that have P21 and P31:Q5.

The last two are problematic - persons that have now some P31, but not Q5, and have not P21. They will be in the 13-elements category, when they should not. What do you think? Thank you.

MisterSynergy (talkcontribs)

Hey IKhitron, sure I remember you.

I'm on a holiday trip this week without a suitable device for Wikidata work. I will look into your comment next week and reply here on my talk page. Kind regards!

IKhitron (talkcontribs)

IKhitron (talkcontribs)

?

MisterSynergy (talkcontribs)

Uhm sorry, I completely forgot this thread (I’m much more busy in real life than earlier this year). I will look into it again this weekend!

IKhitron (talkcontribs)

No problem. Believe me, I was sure you are not silent in purpose.

MisterSynergy (talkcontribs)

Hey again, now there should be some time to solve this issue.

Let me first summarize what we did until now, to make sure that we talk about the same issue:

  • You work at hewiki in the field of lua modules that track Wikidata items associated with hewiki articles
  • The idea is to sort hewiki articles into maintenance categories, if one can improve their Wikidata items

Right?

I don’t really have an overview of the 24 cases you’d like to track. As far as I understand, most of them already work as desired, there are only two (?) cases which we need to think about (your comment from Feb 28). Those are person articles, whose Wikidata item don’t have either P31:Q5 or P21, and thus go to a maintenance category that they are not supposed to be in.

All right so far? If you confirm, I continue here… Best Regards!

IKhitron (talkcontribs)

Hi. Thank you for your answer.

Almost.

It's Lua or templates.

Yes, this is the idea.

The 24 are just all the world.

It will be only 2 rest, if you agree with my suggestion to change your algorithm. What do you say?

They indeed do not have P31:Q5 and P21, but they do have some other P31.

All the rest is right.

MisterSynergy (talkcontribs)

Which suggestion do you refer to? “I think there should be a difference in the code you proposed, to catch much more cases: If the item has P21 and does not have P31:Q5, it should go to a new tracking category, that should be regularly emptied.” from Feb 28?

IKhitron (talkcontribs)

Indeed.

MisterSynergy (talkcontribs)

Yes, good idea.

Does it already solve all your problems, or do you have more?

IKhitron (talkcontribs)

Great, thanks.

As I said, there is a last problem I don't know how to solve.

MisterSynergy (talkcontribs)

Which is the problem of person items with a P31, but no P31:Q5 and no P21, I guess.

Good question what to do in that case. I guess the number of those items is pretty small (is it?), and they will probably be found and fixed at Wikidata without a category as well after some time. A solution could be to technically “ignore” this case in your code, and regularly look into the non-person tracking category whether any persons mistakenly show up there. I don’t see a robust procedure to find these items, unfortunately.

IKhitron (talkcontribs)

I see. Exactly as I was affraid. Well, I'll suggest this on our wikidata phorum, and be back with the community answer. Thank you.

Reply to "Special:diff/448430470"
Horcrux92 (talkcontribs)

Hello! Why did you classified volleyball (Q1734) (and other sports) as type of sport (Q31629) and not sport (Q349)? If volleyball is instance of "type of sport" what would be instance of "sport"?

MisterSynergy (talkcontribs)

Hey Horcrux92, this is the way we generally model item relations here at Wikidata. Whether to use instance of (P31) or subclass of (P279) is sometimes not so obvious, but in this case volleyball (Q1734) simply follows the way all the other types of sport are defined; there is also a lot of very similar P279 structure outside of the field of sports. The subclass relation to sport (Q349) is particularly important for the use of volleyball (Q1734) as a value of sport (P641), while the instance-of relation – regardless of its value – is not at all important to be honest. It is merely a placeholder to equip volleyball (Q1734) with an instance-of value, also similarly as in other items about types of sport.

Did you rely on P31:Q349 somewhere, e.g. in an external application of in a Wikipedia template/module? I’d help to find alternatives in this case, if you need help.

Regards!

Horcrux92 (talkcontribs)

No, I don't make use of Wikidata's data anywhere.

Yeah, I know other examples of usage of the subclass-of property instead of the instance-of one. For example, with musical instruments: we have that guitar (Q6607) is subclass (and not instance) of musical instrument, because an instance of the class – if we want to use an ontology notation – "musical instrument" would be a single and concrete instrument (for example, my guitar :-), that clearly is not notable).

But for the sports it's kinda different: the single and concrete sport is volleyball itself. Honestly, I don't know here on Wikidata, but in a generic knowledge base it is important to precisely declare what is instance of what, because doing this we are connecting an intensive level of knowledge with an extensive one.

MisterSynergy (talkcontribs)

I understand your discomfort about this situation, and indeed it is to some extent controversial at which point we use P31 or P279 instead. Not really in this case, however.

The P31:type of sports is from my point of view (influenced by German and English language) the much more natural claim which I would have even chosen if I did not knew about the Wikidata way to model items. I don’t even see a possibility to have a P31:Q349 claim in any item — Q349 and its subclasses can only be subclassed, not instanced. There are currently 95 of these “instance of sport” which I will continue to work on. I spend a lot of effort into the organization of these sports items, thus I’m interested in this field anyway.

Regards!

Joyce's Ulysses (new items and properties?)

11
Timmy Finnegan (talkcontribs)

I want to flesh out the data on Joyce's Ulysses as far as I can uncontroversially. Is it okay to create new items for, eg, all characters in the book? More problematically, I really want to add a bunch of new properties for describing people: hobbies, routines, possessions, tools, friends, costumes, diet...? What's the approved procedure for this?

MisterSynergy (talkcontribs)

Hey Timmy, you can find the relevant policies regarding item creation at Wikidata:Notability. tl;dr: items with sitelinks to any Wikimedia project are okay, items with “structural need” as well, and some more… . If you create new items without any sitelinks please make sure that they are actively used by other items. Characters could be linked to the main work as for instance in Tom Buchanan (Q18710699), which links to and is linked by The Great Gatsby (Q214371) (you can use Special:WhatLinksHere to check whether the item is used in the main namespace).

Regarding properties: there are already ~3.000 properties available, you can find them listed on Wikidata:Database reports/List of properties/all and several other pages. If you still think there is something missing, feel free to propose a new property at Wikidata:Property proposal (or one of its subsections). This is a formal process where you need to describe the intended use, and if concensus is reached, someone will create it within a week or so. It might also happen that users advice you to do things differently than originally thought instead of creation a new property, which should also be okay.

Hope that helps? Otherwise feel free to continue here. Regards!

Timmy Finnegan (talkcontribs)

Maybe we need a 'Personality' Wikiproject whose purpose is to brainstorm ways to describe human characters more vividly? (and archive these debates.) I see that 'friend of' got created as 'significant person', but I haven't found anything for hobbies or tools or possessions or diet or costume. If I read you right, it's fine to add Ulysses characters so long as they link to the book, plus to at least one other character?

MisterSynergy (talkcontribs)

For an important work such as Joyce’s Ulysses this is indeed no problem at all to have all individual characters equipped with an individual item. This would be different for less important work, although I don’t know where exactly this transition to “less important” happens.

You can look for WikiProjects on Wikidata:WikiProjects. There is likely already information available, maybe distributed to several projects. The best place to ask the entire community for advice – even in specific fields – would be Wikidata:Project chat.

Some suggestions anyway:

  • hobbies might be described by occupation (P106), which is not limited to professional occupations; however, it is often difficult to substantially source hobby activities.
  • for tools and costumes, uses (P2283) could be useful
  • ditto owner of (P1830) for possessions (or do you mean possession as a medical condition (P1050)?)
  • I have no real idea about diets at the moment…

Regards!

Timmy Finnegan (talkcontribs)

I'm trying to understand "substantially source" which I'd think for my purposes would normally be a page number in the 1922 edition-- but does anybody really bother? I can't find any showcase items that offer anything useful. Next most common would be Ellmann's biography, but it doesn't even have a Wikipedia page.

Timmy Finnegan (talkcontribs)

Also, am I cheating if I use the 'carries' property for people carrying items?

MisterSynergy (talkcontribs)

Okay I see, this question is specifically about a fictional character. With real humans it is indeed complicated to provide reliable sources for hobby activities, and for that reason the occupation (P106) property is typically used for occupations with encyclopedic relevance (i.e. that would suffice for a Wikipedia article about that person), but not for hobbies.

I don’t have any other idea right now than to use P106 (which formally includes hobbies) or propose a new specific “hobby” property.

MisterSynergy (talkcontribs)

Regarding carries (P2505): that is not possible. This property can only be used in items about bridges, tunnels and mountain passes.

You can learn about allowed uses on the talk page of properties, which is Property talk:P2505 in this case. There are formal “constraints” applied in a somewhat complicated manner which lets items appear on constraint violation lists such as Wikidata:Database reports/Constraint violations/P2505 in case of wrong use.

Timmy Finnegan (talkcontribs)

The item 'Ulysses' has properties 'edition(s)' and 'translator'. (It doesn't yet have 'edition or translation of'.) Q6511

It seems wrong to list translators without mentioning the language or linking the translation.

Ulysses is unusual in having multiple English editions that disagree on minor issues, especially pagination. So source-references for details of the text need to specify edition-plus-page. The 1922 edition is available on Wikisource where each page has its own url: https://en.wikisource.org/wiki/Ulysses_(1922)

Is there any precedent for handling these complications? I'm guessing there needs to be a distinct item for each edition, that could include the url if that edition is online. (Online versions usually introduce new errors, too.)

MisterSynergy (talkcontribs)

You can create items for each relevant edition of this work. Right now there are no label (Q15996608) and Ulysses (Q19020726) as far as I can see, but this can be done for each edition separately. You would then use the translator (P655) and language of work or name (P407) properties within the edition item, as shown in the example above. The individual editions are then linked to the work by the edition(s) (P747) property.

How to then compile a source is described in Help:Sources#Books. This look a little lengthy, but includes the creation of a source property if necessary.

Timmy Finnegan (talkcontribs)

Wikidata:WikiProject Books is a big help

Edgars2007 (talkcontribs)

Wanted to say many thanks for the job!

I wanted to get this done before shutdown, so we can have clean values (continuation in next passage). If we later will have mapping of old->new IDs, this clean-up will be invaluable. If we don't get mapping (and URL redirects won't work), this of course will be wasted time :D

(continuation) the only thing (for clean-up) that is left, is verification, that we have correct IDs for the particular person (at least by name and/or YOB). I was thinking of some name/id matching script, but as usual haven't moved forward than idea. Will be honest, there have been some mistakes in imports :) (to get more IDs, the quality gets damaged)

MisterSynergy (talkcontribs)

If I remember correctly the links will be useful for “the new SR” in some manner as well, so let’s hope that this is indeed the case. At least I found some mistakes and fixed them properly, there have also been some ~15 mergers based on this process.

A verification of the person–ID relationship would be useful, but I would not expect many flaws here. The relationship has meanwhile been tested in so many ways that I think our SR catalogue is pretty good in shape right now. However, I once used a (self-built) script that crawled an external database (not SR) and extracted information by HTML scraping thereafter for a comparison with data in Wikidata. This worked pretty well, and I do work on this script for broader application. It is not ready for use right now, but will be so rather soon. If I now crawled SR completely, I could even do the evaluation later.

Edgars2007 (talkcontribs)

Yes, most of unique value violations after my imports usually are valid mistakes, as they are source for item merge.

Of course, I can write such script myself (actually I have one for participant of (P1344) and sex or gender (P21)), but scraping approx. 120tk profiles - sorry, won't take it, too much for me and my Internet connection. If you could simply scrape all useful data (their infobox and result tables), that would be f* COOL! I could later help/do with comparision and data addition to WD. I simply need data to work with :)

MisterSynergy (talkcontribs)

Well the problem with Sports-Reference is that we somehow run out of time. If I crawled Sports-Reference completely, I would like to do it from Tool Labs with a custom HTTP User Agent – this is not possible right now. Data transmission itself shouldn’t be a problem (I would expect 1–2 GB for all profiles). But since they require bots to crawl only once every three seconds via their robots.txt file, the crawling rate must be rather low (I wouldn’t do it faster than 1/5s) – and an entire crawl takes roughly a week if nothing fails.

Edgars2007 (talkcontribs)

Then we should start moving forward :) Otherwise we will be lost (in Latvian there is saying for such situations, but can't find anything good in English).

And if there are two crawlers (both from Tool Labs)? From different IPs? One starts with 'a' and other - 'z'.

MisterSynergy (talkcontribs)

Well, I don’t think we should risk getting banned by them. The crawl-delay instruction is meant to limit the load on their servers, and they know best what their servers can cope with. My crawler is built to “fully” respect robots.txt files.

Anyway, reading Bill Mallons recent comments I am pretty optimistic meanwhile that “the new SR” will have at least similar quality as the old one. I think it is worth to take the risk and wait for the new SR one to work with it then. We could also think of imports and addition of references then.

82.131.126.169 (talkcontribs)

Okay, I understand that it is an absolute no-no to add any data without references, hence this reversal: https://www.wikidata.org/w/index.php?title=Q12365424&type=revision&diff=425660242&oldid=425572907 The only thing that makes me wonder is why the heck did you reinstate a single claim which was, also, given without any reference or proof? No need to answer me, just try to find a convincing answer to yourself.

Also, it might help if you would think about why people who come to Wikipedia first time usually never return.

MisterSynergy (talkcontribs)

Hello IP user!

It is true that we typically want to see reliable, external sources for all data which is hosted at Wikidata. However, for various reasons this is not an easy task, and we are working hard for a satisfying solution at some point in the future. This also includes accepting unsourced data at Wikidata, as long as it is reasonable to assume it is correct. This applies to my opinion for the country of citizenship of John Deely (Q12365424), thus I re-added it after it got lost during the revert.

The situation is a little different with the death date of this person, which is said to be just two days ago. We have ongoing trouble with death notes of still living persons in the Wikimedia universe, and typically prefer to wait until there is a reliable external source which verifies the death of the person in question. It does not cause any trouble if the death note does not appear immediately at Wikipedia (or Wikidata); it potentially does, however, harm a lot if the person actually has not died, and external media or search engines such as Google are picking this information up (they do, even right now).

Since I was not able to find an external source for Deely’s death, I removed the claim. It typically takes some days until a reliable source shows up.

Best regards!

DGtal (talkcontribs)

Why was [https://www.wikidata.org/w/index.php?title=Q2389615&diff=next&oldid=382434226 this claim] removed? ~~~~

MisterSynergy (talkcontribs)

Because it was a claim without a reference, one among ~5.000 unsourced sexual orientation (P91) claims. I raised attention for this problem at Wikidata:Project chat#Unsourced sexual orientation (P91) statements after a large import of unsourced claims from Wikipedias brought this problem beyond the point of possible repair. There was quite some discussion, but in the end consensus to remove unsourced claims of this particularly difficult property.

This does not mean that data about sexual orientations is forbidden here at Wikidata. We just expect valid sources, as stated on Property talk:P91 for a long time now. If you can provide a valid source, feel free to re-add the claim again.

DGtal (talkcontribs)

OK. I'll now add a source I found online

Edgars2007 (talkcontribs)

Hi! Please remove Latvian (lv) from Name guzzler language list. Although we Latvians are using Latin alphabet we have pretty complex rules how to write person's name in Latvian. It's almost always ≠enlabel.

MisterSynergy (talkcontribs)

Thanks for your comment! Here are at least to more users you’d like to ask for that: https://www.wikidata.org/w/index.php?title=Special:Search&profile=default&fulltext=Search&search=User%3A+intitle%3A%22nameGuzzler%22+insource%3A%2F%5C%27lv%5C%27%2F&searchToken=drg59ea9sav1a7b2shsz4hc8h.

Is there any possibility to determine a Latvian name automatically from its original Latin-script language?

MisterSynergy (talkcontribs)

There are even much more: https://www.wikidata.org/w/index.php?title=Special:Search&profile=default&fulltext=Search&search=User%3A+intitle%3A%22nameGuzzlerOption%22+insource%3A%2F%5B%5C%27%5C%22%5Dlv%5B%5C%27%5C%22%5D%2F&searchToken=6egifrry5p5t1wic369lsytgl

Forget about the other link ;-)

Edgars2007 (talkcontribs)

Thanks for the link.

Hmm, about that automatical determining... Would be good, but no, there isn't any.

MisterSynergy (talkcontribs)

Well then you got a lot of work to do… :-)

Shall I try to tidy up a bit, at least those cases where I (probably) made this edit? With rare exceptions I use nameGuzzler only for rowing people, so I could query them and try to remove the potentially non-Latvian labels again.

Edgars2007 (talkcontribs)

I'll be simply removing them with bot. Have to construct a SPARQL query, which will be good enough (not including Latvian guys).

As you have been one of those users who cleans my mess with Sports Reference, so I can do this Latvian label thing myself :)

JarrahTree (talkcontribs)

Anna Livia Julian Brawn

your edit I reverted - because:

Was a personal friend in real life, - I know very definitely that in her last years she was living with her female friends, as well as having a range of novels earlier in her life that were published by lesbian publishing houses - I am not sure where your edit came from, please feel to ask me further if you have to - also the photo in her article was when we were taking photos of each other... cheers ~~~~

JarrahTree (talkcontribs)

Q4767237

MisterSynergy (talkcontribs)

JarrahTree, there was a discussion on Wikidata:PC (meanwhile archived) on the matter of unsourced sexual orientation (P91) statements. Such information can be quite delicate depending on where one lives on this planet (plus there is a lot of vandalism involving P91), thus the talk page Property talk:P91 clearly states that this property shall always be used with an external source in which the person itself claims their sexual orientation (deceased persons: historians are sure about that). It turned out that more than 90% of all usages violated this rule, thus I removed them after a longer discussion with the community.

However, information about a person’s sexual orientation is explicitly not forbidden at Wikidata. You can of course revert my removal, but I kindly ask you to provide external evidence for that claim regarding to Help:Sources. Enwiki, where this information was imported from, might be a good place to start looking for external references. If you do not provide such a source, the data might be removed again in another removal run in future.

Regards!

JarrahTree (talkcontribs)

I can understand the issues arising. I wrote the article for a start. Anna was lesbian - from the details of her biography, her publications, and her obituaries specifically identify her female partners - simply - a check of the article and the refs there, if it helps I will add a ref here as well, interesting, almost 10 years since she died.

JarrahTree (talkcontribs)

Oh sorry, - thank you for your thorough reply, I can imagine it must be a hard job keeping up with something like that

JarrahTree (talkcontribs)

and to follow up I have added the obituary that qualifies what I have asserted here - thanks for your help understanding the importance of doing that

MisterSynergy (talkcontribs)

Yes, there are a couple of other properties with the same problem, such as ethnic group (P172), religion (P140), and maybe a handful of others, but less than 10 I guess. I did not start to look into their condition, but I do not think it is any better than P91 was before that removal of data.

Regarding Anna Livia Julian Brawn (Q4767237): there is this obituary you’ve just added as a reference, and I think it is a good source. I’ve added some information to this reference…

JarrahTree (talkcontribs)

She was a very nice person, and I have for the last 10 years thought about what she left behind, I am sure she would be amused to think that from the time b&w photos we took of each other, to now, that what we have made here, the she is remembered in something she never imagined would happen...

Thank you so much for the formatting of the ref - i must take note of how to do that !!!!

MisterSynergy (talkcontribs)

One more thing:

Before data removal we considered adding sources to all unsourced P91 claims instead of just removing them. With an optimistic estimation of 2.5 minutes per claim and ~5000 affected items we found that it took at least 200 hours of work to repair the situation just for P91. It was pretty clear that no editor would ever spend this effort. The removed claims were almost always imported from Wikipedias with their own rules about sourcing, so the information is not entirely lost from Wikimedia’s universe. Unfortunately it is easy to import some data from Wikipedia, but it is not easy at all (it’s even impossible in most situations) to also add a valid source at the same time.

Regards!

JarrahTree (talkcontribs)

Very very interesting . I have problems with BLP articles on wp en - where editors who should know better fail to add specific project templates on the bio articles they are creating point out the time it takes to do things. When I look at my wp en editing, I would not want to hazard a guess at how many hours of my life I have lost to wp en :(

JarrahTree (talkcontribs)

Also thank you for your further edits on that item, appreciated

MisterSynergy (talkcontribs)

Oh well this enwiki thing… as a non-native speaker I avoid to be involved there too much, I only fix mistakes I typically find via comparisons with information from Wikidata. But I am still surprised how and why this seemingly chaotic project (compared to my German homewiki) actually works … and I’ve stopped wondering about.

That said: I need to go back to work now, and wish you a great day!