LesserJerome

Welcome to Wikidata, LesserJerome!

Wikidata is a free knowledge base that you can edit! It can be read and edited by humans and machines alike and you can go to any item page now and add to this ever-growing database!

Need some help getting started? Here are some pages you can familiarize yourself with:

• Introduction – An introduction to the project.
• Wikidata tours – Interactive tutorials to show you how Wikidata works.
• Community portal – The portal for community members.
• User options – including the 'Babel' extension, to set your language preferences.
• Contents – The main help page for editing and using the site.
• Project chat – Discussions about the project.
• Tools – A collection of user-developed tools to allow for easier completion of some tasks.

Please remember to sign your messages on talk pages by typing four tildes (~~~~); this will automatically insert your username and the date.

If you have any questions, don't hesitate to ask on Project chat. If you want to try out editing, you can use the sandbox to try. Once again, welcome, and I hope you quickly feel comfortable here, and become an active editor for Wikidata.

Best regards!

And congratulations for your first OpenRefine import, it looks perfect! − Pintoch (talk) 15:34, 8 January 2019 (UTC)

• Pintoch Thank you! Your tutorials were very clear, and I'm glad the import has your stamp of approval. I've been trying to learn about linked data for a little while now and this was my first ever batch contribution to any kind of project whatsoever. Looking forward to further contributions. LesserJerome (talk) 16:40, 8 January 2019 (UTC)

NHL Stats

Hello! Look at wrong dates[1]!Сидик из ПТУ (talk) 16:22, 1 March 2019 (UTC)

Сидик из ПТУ I obtained the years of the career from Hockey-Reference.com's franchise pages. For this player's information on his two teams' pages, LA Kings and Nashville Predators, the years are given 2000 to 2002 and 2002 to 2002 respectively. So these are the seasons he played in, the span of his career, and that's what I've uploaded. Adding the exact dates of the first and last goals is not what I had intended to represent with the start time and end time qualifiers, only that between the start of his career in the NHL and the end of his career, these are his stats. I think this time frame is more significant, because that's important to know that he played for some time after February 10, 2001, but never scored a goal - there was a significant time of his career where he was trying to score, but never scored. You had mentioned before that a separate property would be useful for "date of most recent value change" - that would be different from "end time." What do you think? LesserJerome (talk) 18:40, 1 March 2019 (UTC)

2000 as begin date for player who first scored at 1999 is weird and not common. I think, property for total career games needed. For example, 134 (December 11, 1999 — April 14, 2002) for Jere Karalahti (Q1342283). So then everyone can find out his NHL debut date and understand that "he played for some time after February 10, 2001, but never scored a goal". And for 0 values no dates required. Сидик из ПТУ (talk) 17:59, 1 March 2019 (UTC)

Сидик из ПТУ I do not think a property for total career games is needed - that is covered number of matches played/races/starts (P1350), which is partially described as "a total number of matches a player officially appeared in during the whole career." I think this is sufficient, when it is qualified by league, but you removed the edit and I'm not sure why.

I'm suprised by this my edit. I think it was my blooper.Сидик из ПТУ (talk) 19:43, 1 March 2019 (UTC)

You are right, though, that the date 2000 is wrong for the start of this particular player's career. It should be 1999. I looked at a few other players and it appears that the career start date data is consistently one year later. I think I should be able to fix this for all of them - leave it to me and I'll take care of it. Thank you for bringing this to my attention. LesserJerome (talk) 18:40, 1 March 2019 (UTC)

Сидик из ПТУ Update: I am rolling back my bulk import of stats and I will upload them again with corrected start dates on Monday. Thanks for catching such an important error! LesserJerome (talk) 19:00, 1 March 2019 (UTC)

Let us first discuss as much as possible the expected results of the fill, and only then it will resume. "1999" willn't make any sense to users of this stats. So either we specify "December 30, 1999" as start time (P580) for Jere Karalahti (Q1342283) of NHL goals, or we somehow specify 1999–2000 NHL season (Q1756146). NHL seasons will be specified by participant in (P1344) and I don't see any reasons to duplicate these obviously coinciding boundaries in each of the statistical properties. In this case, start time (P580) and end time (P582) will be wise to use precisely for what I suggest. Сидик из ПТУ (talk) 19:33, 1 March 2019 (UTC)

Сидик из ПТУ I appreciate your thinking, but I have to disagree. First, I think using a year in the start time (P580) and end time (P582) properties will be totally clear to anyone looking up these stats. If we say "Gretzky scored 894 points between 1979 and 1999," we don't need any more information to understand what is meant. While it would be correct to use hockey seasons, if we could find a way to make it work, this more complex schema is not absolutely necessary right now to convey the information. I would rather have this data up and available in a simpler form than not have it available at all because of technicalities. Also, I have the start and end time data for all these players as years right now, and I do not have the capacity to capture the exact date with month and year that each individual player scored their first and last goals. So I am going to upload this data, but I would be more than happy if someone came along after me to flesh it out with exact dates. LesserJerome (talk) 14:48, 4 March 2019 (UTC)

I repeat that your slant will lead to purposeless duplication of information about the periods of the players in the league. These time boundaries can always be verified by number of matches played/races/starts (P1350). Wikidata is a technical storage of information that is only required to be prepared for presentation in a readable form, we should strive for the most optimal solutions. I don't see a problem in getting "1979" from "October 1, 1979" for any reasons, but I see a problem in overloading the database with duplicate data. I suggest first to find a consensus than to fill. First ever example of using this properties should be ideal.Сидик из ПТУ (talk) 15:24, 4 March 2019 (UTC)

Сидик из ПТУ I see, I think I was misunderstanding you. You mean that it doesn't make sense to have the exact same start and time for every statistical property - it would just be repeating information that is obviously the same. Yes, that's a completely fair point, and one I had thought of too. So if we can make statements for each hockey player about their participation in the NHL, when we say that each statistic was achieved in the NHL, the time is inferred. Do I have that correct? If that's right, we can just use the league (P118) property with start time and end time qualifiers? LesserJerome (talk) 16:00, 4 March 2019 (UTC)

Yes, you can add start time and end time qualifiers to the league (P118) in your way since more accurate dates are difficult to determine in this case. Again, then the start time (P580) and end time (P582) for goals and assists must mean exceptionally accurate dates of the first goal and the last goal, etc.Сидик из ПТУ (talk) 16:31, 4 March 2019 (UTC)

Anyway, it would be nice to fill Hockey-Reference.com player ID (P3598) and participant in (P1344) too. Сидик из ПТУ (talk) 15:29, 4 March 2019 (UTC)

As far as I can tell, Hockey-Reference.com player ID (P3598) is complete for NHL players. Do you think league (P118) could be a better choice than participant in (P1344)? I know you were thinking participant in (P1344) for individual hockey seasons, but it could be more succinct to simply say that a player played in a league from this year to this year. LesserJerome (talk) 16:00, 4 March 2019 (UTC)

There was no Hockey-Reference.com player ID (P3598) at Jere Karalahti (Q1342283) after your edits. I think "1999" is more ambiguous than 1999–2000 NHL season (Q1756146) or 1998–99 NHL season (Q680030). Better to fill both properties. Сидик из ПТУ (talk) 16:31, 4 March 2019 (UTC)

Сидик из ПТУ I didn't add the Hockey-Reference.com player ID (P3598) statements, they were already uploaded. Jere Karalahti (Q1342283) does have a Hockey-ReferenceID on his page: k/karalje01. As for participant in (P1344) statements, do you propose one statement for every NHL season a player played in? LesserJerome (talk) 17:08, 4 March 2019 (UTC)

It was added by me. As for participant in (P1344) statements, I propose one statement for every NHL season and another one for every Stanley Cup (Q211872). Although this property is so ambiguous that at least every match can be added there… I hope in the future will be taken restrictive measures, but the seasons look great use. Сидик из ПТУ (talk) 18:37, 4 March 2019 (UTC)

And how do you build your query? If you do it with the use of software code (for example, on the .NET Framework (Q5289)), then I think it will not be difficult for you to get the first and last dates of the goals using this query, which depends only on the known player id.Сидик из ПТУ (talk) 15:42, 4 March 2019 (UTC)

I haven't been doing anything too advanced - mostly just copying data from tables available online and manipulating it in spreadsheets and OpenRefine. I'd love to learn how to scrape the web properly though. LesserJerome (talk) 16:00, 4 March 2019 (UTC)

Let's try to do the following: you will send me a list of ids from Hockey-Reference.com (Q28649144) (for example, in the .txt format), and I will try to write a simple little program that returns this ids with the date of the first and last goals. I expect to cope in a day.Сидик из ПТУ (talk) 16:31, 4 March 2019 (UTC)

That sounds great - I can definitely do this for you. What's the best way for me to send you a file? LesserJerome (talk) 17:08, 4 March 2019 (UTC)

You can use mail system.Сидик из ПТУ (talk) 18:37, 4 March 2019 (UTC)

Сидик из ПТУ I looked into using the Wikimedia mail system and I wouldn't be able to send you a file that way, unless I'm mistaken? LesserJerome (talk) 19:30, 5 March 2019 (UTC)

You should send me just "Hello!" or somethinh like this and ater my reply we will be able to use our standard mail systems bypassing Wikimedia.Сидик из ПТУ (talk) 19:47, 5 March 2019 (UTC)

Wikidata:Property proposal/date of the latest value change. Сидик из ПТУ (talk) 19:19, 13 March 2019 (UTC)

Hello! I think it would be wiser to use point in time (P585) for players with only one goal like Evgeny Shaldybin (Q742594). Сидик из ПТУ (talk) 22:04, 18 March 2019 (UTC)

Hmm, I guess that makes sense. My one concern is consistency with other statements using this property. If I was to query Wikidata for this property and used the start time and end time qualifiers to do so, would that pick up statements using only a point in time (P585) qualifier? Is the ontology able to handle that? If so, do you have any ideas for how to fix this? LesserJerome (talk) 13:37, 20 March 2019 (UTC)

Look to Aggie Kukulowicz (Q4692209) here. Сидик из ПТУ (talk) 15:46, 20 March 2019 (UTC)

Can you explain this to me please? LesserJerome (talk) 16:28, 20 March 2019 (UTC)

Aggie Kukulowicz (Q4692209)'s goal has specified with point in time (P585), but we can all the same sort all players by their first goals. Сидик из ПТУ (talk) 17:09, 20 March 2019 (UTC)

Another idea is not to specify a property for the value 0. Justin Bieber (Q34086) has 0 assists in NHL too. Сидик из ПТУ (talk) 22:07, 18 March 2019 (UTC)

Сидик из ПТУ I appreciate your argument, and I mean no disrespect, but I think it's slightly nonsensical. Of course Justin Bieber has no assists in the NHL. He never played in the NHL. You could not legitimately use an of (P642) National Hockey League (Q1215892) qualifier for any of his statements. Put another way, we can't always worry about defining every single negative statement: on Justin Bieber's page, we wouldn't list everything he hasn't done or everything that he isn't, that would be absurd. On the other hand, it is meaningful that an NHL player actually played in the NHL, had an opportunity to record a statistic, and failed to do so. Including a zero where a player hasn't recorded a goal or assist is common practice, and you'd expect to see it in any standard presentation of stats. Plus, looking at the dataset as a whole, it is meaningful to see that a number of players have zeros in some categories as compared to those that have positive integers. LesserJerome (talk) 13:37, 20 March 2019 (UTC)

It is even better for the database if players with zero goals are not selected at all due to the lack of a corresponding property. Otherwise, to get a list of all NHL goalscorers, you will need to specify the query "where the property is exist and it is not zero". Сидик из ПТУ (talk) 14:01, 20 March 2019 (UTC)

And as far as I understand, usually they do not store amounts in databases - they are counted when querying, so there is no point in storing zeros. Not found - it means there is zero. But do not forget about value unknown option.Сидик из ПТУ (talk) 15:54, 20 March 2019 (UTC)

Can you please explain what you mean by "they are counted when querying"? I don't think I understand. If not found means it is zero, then that includes Justin Bieber, as you said before. Also, if a player did not score any goals, simply not including a statement for goals just looks like someone forgot to include information. I think it most straightforward to use zeros, then you can search for players who have "0" goals and not simply players who do not have property statements for goals at all:

SELECT ?player ?playerLabel ?goals
WHERE 
{
  ?player wdt:P6509 ?goals.
  ?player wdt:P118 wd:Q1215892.
  FILTER (?goals = 0) .
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}

Try it!

LesserJerome (talk) 16:28, 20 March 2019 (UTC)

Typically, numerical values are counted for queries, rather than being made ready from the cells of the tables. If the count function does not find any suitable records, it returns 0. In any case, we create Wikidata not for viewing individual elements, but for using this data in the form of queries or infographics. It is quite possible for the purpose of optimization to agree that zero values in the general case are not the reason for filling the property. After all, you can then add to the players without Twitter no value mark in X username (P2002). And are we still assume that all the players were processed correctly? In other words, we expect that at the time of the request there are no such players who have forgotten to specify 0. At the moment it is not. There are players with hundreds of goals without total goals in career (P6509), there are players with zero goals without total goals in career (P6509). It is especially funny that then for 99.9% of goaltenders will have to fill in zeros for goals, assists and other indicators of field players and vice versa too! I can’t pick up an analogy for hockey, but in basketball, then it will turn out to be even more absurd 0 three-point field goal (Q746826) for players from the 1950s… My query is here, it's not more difficult than yours, but implies more optimal data storage.Сидик из ПТУ (talk) 17:09, 20 March 2019 (UTC)

Сидик из ПТУ I think Wikidata should be useful both for individual pages as well as for larger datasets, and should be able to be read by humans and computers alike. I should be able to go to an individual player's page and see their basic stats, as well as see their stats in the larger picture of a dataset. If a human went to a hockey player's page and saw properties for all statistical categories but not for goals, they would assume that someone forgot to add that property. If I went to a hockey players page and saw no stats at all, I would guess that this data hasn't been added yet, but might be added one day. I understand your argument about optimal data storage, but I think we need to balance that with the needs of the everyday user trying to understand the data in the most straightforward way possible. It's a clever idea to simply not make statements where the value is zero, but we can't expect everyone to be clever and to figure that out. I believe explicitly stating zero where it is appropriate to do so is the best solution. So in the examples you've provided, its simply not appropriate to record the statistics - other than in very exceptional cases, goalies don't score, so we simply wouldn't record total goals in career (P6509) statements except in the 11 cases in which it is relevant. Same with your basketball example - the property simply doesn't apply to players in the 1950s, so we don't even think about it. But it is not very exceptional for a forward or defenseman to not score, it's fairly common and should be recorded. We can't reasonably expect everyone to have a Twitter handle or to have recorded statistics in the NHL, but we can reasonably expect NHL players who are not goalies to have recorded non-goalie statistics in the NHL. LesserJerome (talk) 14:44, 21 March 2019 (UTC)

Your concerns about the confusion of newcomers can be dispelled if we simply add to the description of the property do not fill in the case of zero. And it will be a very strange list of NHL goalscores with Evgeni Nabokov (Q390913) (1), Fedor Fedorov (Q1341732) (0) but without Dominik Hašek (Q312695) (0). Even more strange will be the situation with the goaltenders assists, because half of them have assists on their account with half doesn't have[2]. Thus, with your way, half of the goaltenders will have total assists in career (P6545) with 0 and in this case newcomers are likely to perceive the lack of a total goals in career (P6509) as an error that should be corrected. Сидик из ПТУ (talk) 15:51, 21 March 2019 (UTC)

• Another problem[3].Сидик из ПТУ (talk) 18:11, 20 March 2019 (UTC)

Сидик из ПТУ This data came from the list you sent to me, so I'm afraid the error originates with your data scraping. LesserJerome (talk) 14:44, 21 March 2019 (UTC)

Yes, but I warned you that detailed statistics on the resource starts in 1979.Сидик из ПТУ (talk) 15:51, 21 March 2019 (UTC)

• And one more remark. As far as I understand, if the source is the identifier specified in the item, then adding the reference URL (P854) to stated in (P248) is not required. For example, Viktor Semyashkin (Q1986769) has described by source (P1343) with detailed link to encyclopedia (page number, article name) and in other statements we use only Athletics. Encyclopedia. Volume 2 (in Russian). (Q50015089) when referring to this article with ISBN specified in the item of book. Сидик из ПТУ (talk) 17:33, 21 March 2019 (UTC)

NHL PIMs

• Just a note that it looks like there was an error in your bulk update of the career player NHL stats after the 18/19 season. Specifically it looks like the data that was meant to go into the career penalty minutes property has ended up in the career +/- and vice versa. You may need to revise and or repopulate.CanadianCodhead (talk) 16:32, 2 July 2019 (UTC)
  • CanadianCodhead, Сидик из ПТУ, Thanks for the notification -- I am undoing my bulk edit that contained the errors. I'll put the stats up again, this time correctly and with qualifiers, and I'll double-check my work. Sorry about that, I should be more careful! LesserJerome (talk) 16:43, 2 July 2019 (UTC)
• I'm not sure if you are able to implement this, but i added a note on the project chat page, that possibly a constraint should be added so that the stats that can not ever be negative (games, goals, assists, points, PIM) can not accept a negative number. That way if anything similar happens, it should catch the problem.. No worries about the transposition, we all do them.
  • CanadianCodhead I replied to your note on the project page and took a crack at adding some constraints to the properties I proposed, let me know what you think. Thanks for helping me improve these properties. LesserJerome (talk) 12:34, 3 July 2019 (UTC)

Ontology of statistics properties created by you

Hi, first of all, I apologize for discussing this topic once you have made thousands of information inputs, but I have now found these new properties. I work in the construction of infoboxes fed by WD. Periodically, I check what new properties I can use to show them in infoboxes. Your property collection P6509, P6543-47 is conceptually very useful not only for hockey but also for other sports that use similar statistics. Certainly. In fact, they must be followed for some other similar properties with statistic information of other sports. However, the ontology, that is, the data structure of these properties in relation to the element and the other properties and qualifiers, I think it is not correct. I do not know if you are familiar with these concepts. I explain my opinion. These properties speak of "a sport's entire life" of a person, so it seems reasonable that they are property of the article (the sports player). However, they are not a unique "great total", since it is related to a sport. The data structure of WD should be able to manage that someone had played in more than one sport. To solve this, your proposal has been to add a classifier of (P642) in the sports league. It's a way.

IMHO, these properties have to be harmonized (ontologically speaking) with similar previous properties as number of points/goals/set scored (P1351) and points for (P1358). These properties are defined as "qualifiers", since their value is a characteristic not of the person, but the person who plays as a team or in sport or sport. In the case of your collection, they must be a qualifier of the league (P118) of the person. In this way, each league has all the elements related to the life of the athlete when he played in this league (dates and overall results). Example:

⟨ Patrick Traverse (Q363536)    ⟩ league (P118) ⟨ National Hockey League (Q1215892)    ⟩
start time (P580) ⟨ 1995 ⟩
end time (P582) ⟨ 2006 ⟩
number of matches played/races/starts (P1350) ⟨ 279 ⟩
total shots in career (P6543) ⟨ 260 ⟩
total goals in career (P6509) ⟨ 14 ⟩
total points in career (P6544) ⟨ 65 ⟩
total assists in career (P6545) ⟨ 51 ⟩

... etc.

I do not understand how nobody informed while the process of creating property.

What to do from here? I think we have to share and invite to discuss experienced people in sports and ontology. I did not want to publish it in the discussion page of the property without previous talk with you. This is not a critique of your work, however, it is incorrect and must change before it grows more. If you do not agree or have doubts with my proposal, I suggest to move the discussion to the Wikidata:Project_chat, when you want. Thanks, Amadalvarez (talk) 20:28, 26 June 2019 (UTC)

amadalvarez Hi! Thank you for taking the time to write such a detailed comment. You are right; the properties I proposed should have been harmonized with other properties number of points/goals/set scored (P1351) and points for (P1358). Your example is really helpful and really illustrates how it would be better to structure the information. It makes sense in the ontology and even just looks so much cleaner on the item's page. In hindsight, when I was adding the same of (P642) qualifier to every statement, that should have been a clue that there was a better way to structure the data. So I definitely agree that we should fix this. I can add property constraints to all of the properties I proposed to ensure they can only be used as qualifiers. Would you like to open up a discussion in the appropriate space?

As for all the data I uploaded, that will have to be removed. I think I should be able to remove everything using QuickStatements without too much trouble. I still have all of my data prepared in OpenRefine, so it's very little work to change the schema to fit the correct structure, then I can re-upload the data properly. Do you think I should wait until we have some discussion, or do you think it's safe to re-upload the data so it looks like your example?

Thanks again for your comment, your ideas will make these properties work much better. LesserJerome (talk) 18:32, 27 June 2019 (UTC)

@LesserJerome: Don't worry. All of us were wrong sometime. If you already agree with my proposal, the easy way is go to the discussion page of the properties (may be the first on on behalf of all of them) and proposse the change, inviting the participant people in the original proposal to get their opinion. We can make a partial copy-paste of my message (where explained the new ontology) and ask for opinions and a new agreement. When somebody propose a change on one existing property, the agreement must be done for the proponent, mainly, which usually is the more affected. So, in this case, if you accept the change, should not be a problem. If you're familiarized with quickstatement, I believe is the best way. If you need some help, just tell me. Thanks, Amadalvarez (talk) 19:08, 27 June 2019 (UTC)

Look at league (P118) of Alexander Radulov (Q471377). I think updating career totals with qualifier will be more difficult than with independent properties here. But league (P118) of Alexander Radulov (Q471377) with divided into periods is more correct in terms of Wikidata than union of them. Сидик из ПТУ (talk) 16:33, 28 June 2019 (UTC)

And further. You lose sight of the fact that career totals exist not only for the regular seasons, but also for the Stanley Cup playoffs (Q13567935) or ice hockey at the Olympic Games (Q114581) where league (P118) can't be used by definition. Сидик из ПТУ (talk) 17:51, 28 June 2019 (UTC)

@LesserJerome, Amadalvarez: Hello! I do not agree with the proposed changes. Firstly, with this approach it will be impossible to indicate the date of the first goal in the player’s career (the qualifiers "date of the first one" and "date of the last one" are needed). It will also help to make the rankings of the youngest or oldest authors of goals in the history of the league, and much more. If we have only "1995" as start time (P580) for Patrick Traverse (Q363536) then we lose this info because we cannot use qualifiers for qualifiers. And it may be that retrieved (P813) is correct for total goals in career (P6509) but wrong for total assists in career (P6545), therefore after another match it will be impossible to edit only the goals, you will have to update all the indicators, which can be difficult. Further, if we talk not about Patrick Traverse (Q363536), but about Ilya Kovalchuk (Q434859), then we will have

⟨ Ilya Kovalchuk (Q434859)    ⟩ league (P118) ⟨ National Hockey League (Q1215892)    ⟩
start time (P580) ⟨ 2001 ⟩
end time (P582) ⟨ 2013 ⟩

+

⟨ Ilya Kovalchuk (Q434859)    ⟩ league (P118) ⟨ National Hockey League (Q1215892)    ⟩
start time (P580) ⟨ 2018 ⟩

instead of

⟨ Ilya Kovalchuk (Q434859)    ⟩ league (P118) ⟨ National Hockey League (Q1215892)    ⟩
start time (P580) ⟨ 2001 ⟩

and with this approach it will not be the career totals by league. Сидик из ПТУ (talk) 06:06, 28 June 2019 (UTC)

@LesserJerome, Сидик из ПТУ: Thanks for your considerations. What's the property for "date of the first one" and "date of the last one" ?. The sports ontology in WD is still in an early step of evolution. It's not the same talk about global figures(all sportive life), figures by seasson or team, or running figures as by match (not only number of goals, but also the minut, who did the assistance or where the ball entry for). Obviously, this scenario is far from where we are now. The number of points/goals/set scored (P1351) & points for (P1358) are not linked (in his definition) to a point in time. It allows them to be subordinated -as a qualifiers- under diferents levels of the player's life: a seasson, a team (member of sports team (P54) and, in the future, in a match. I mean that the point in time are the periods in the chronollogy of the player, and the goals are results in each of this periods. To know how many goals somebody did while he plays in a certain team, I espect to find this information under a P54 entry for this club, etc. The collection of properties that LesserJerome proposed are "grand totals", I mean the summ of the whole player's life. As we have to accept that people can play in more than one sport, is obvious that this info must be related to the different sports (or league). The case of Ilya Kovalchuk (Q434859) is easy to solve. If you want to describe with precission that this guy have been in two differenciate period, probably you wish also know the statistic in each of this periods. What would be your proposal to have differenciate both periods and have the total goals in career (P6509), for instance, for the whole life ?. thanks, Amadalvarez (talk) 06:40, 28 June 2019 (UTC)

Properties for "date of the first one" and "date of the last one" will be proposed by me very soon. Look at Wikidata:Property proposal/Total goals in career examples and see that we assumed usage of similar qualifiers, but later we were told that start time (P580) and end time (P582) are not for this. As for the player's goals for the team, we discussed this on the example of football infoboxes (Wikidata talk:WikiProject Association football#Data for automatic infoboxes). In a nutshell: for this data to be useful it is necessary to have a separation of statistics for both tournaments and seasons.

⟨ Lionel Messi (Q615)    ⟩ member of sports team (P54) ⟨ FC Barcelona (Q7156)    ⟩
number of matches played/races/starts (P1350) ⟨ 447 ⟩
number of points/goals/set scored (P1351) ⟨ 416 ⟩

can not be used in Template:Infobox football biography (Q5616966) because we don't know which games were counted here while only domestic legue needed. So statistics in the form of qualifiers to member of sports team (P54) is dead-end. We should have detailed statistics associated with items like 2009–10 NHL season (Q978704) and 2011–12 Copa del Rey (Q557592), but the career indicators should exist independently, as there are cases when the total amount of the career is known, but there is no detail on the seasons. Any periods of Ilya Kovalchuk (Q434859) career shold be counted by seasons summation but it should be allowed to quickly compare career performance too.Сидик из ПТУ (talk) 07:09, 28 June 2019 (UTC)

@Сидик из ПТУ: I understand you. When I talk about qualifiers (not only P1350 and P1351, but all other can we imagine as a cluster of statistic properties) is to be able to have info summarized on the level we choose. Ex: team, league, champinship, seasson, match, etc. If, in addition, you wish a "grand total in his/her life", in my opinion, is equivalent to have a collection of these properties as qualifier of the sport (P641), because for a person who played in two or more sports, it make no sense add point/goals from all the sports. The collection of properties created by LesserJerome are useful to have, too, the "assist", "minutes penalty", "shots", etc. not only at "career" level, but in any other level. It is just a namimg matter. What's the difference between total goals in career (P6509) and number of points/goals/set scored (P1351) of the sport of the player which includes all kind of competitions, clubs and years ?.

Draft not complete

The final objective in your and my proposal are similar, but no the way to do it. The dissapoint is because, while I like to enter the figures as a qualifiers grouped by levels that already have with an item by each (Ex:esport, team, seasson,...), you propose have a main property for each countable concept with the explanation of "when, where and how" as a qualifier. Is it?

When I talked about harmonize is because, for instance, the P1351 already exist and are widely used. In addition, your formula will have just 1 value (if keep limited to a "career") or thousands of values, if we have all the results for all levels under the same property. Well, think about my proposal and let's talking. To help to understant the ontology of concepts (not properties) we have, take a look to schema joined. Thanks, Amadalvarez (talk) 10:58, 2 July 2019 (UTC)

If we recognize the inoperability of the above examples with the statistics of Lionel Messi (Q615) in FC Barcelona (Q7156) and the difficulty of using the joint retrieved (P813) for both matches, goals or red cards then I would suggest to have season statistics like this:

⟨ Jordi Alba (Q187159)    ⟩ number of matches played/races/starts (P1350) ⟨ 32 ⟩
of (P642) ⟨ 2011–12 La Liga (Q207595)    ⟩
of (P642) ⟨ Valencia (Q8818)    ⟩
date of the first one (P7124) ⟨ 10/09/2011 ⟩
date of the last one Search ⟨ 12/05/2012 ⟩
retrieved (P813) ⟨ 02/07/2019 ⟩

⟨ Jordi Alba (Q187159)    ⟩ total goals in career (P6509) ⟨ 2 ⟩
of (P642) ⟨ 2011–12 La Liga (Q207595)    ⟩
of (P642) ⟨ Valencia (Q8818)    ⟩
date of the first one (P7124) ⟨ 26/10/2011 ⟩
date of the last one Search ⟨ 11/04/2012 ⟩
retrieved (P813) ⟨ 02/07/2019 ⟩

⟨ Jordi Alba (Q187159)    ⟩ number of red cards Search ⟨ 1 ⟩
of (P642) ⟨ 2011–12 La Liga (Q207595)    ⟩
of (P642) ⟨ Valencia (Q8818)    ⟩
point in time (P585) ⟨ 21/09/2011 ⟩
retrieved (P813) ⟨ 02/07/2019 ⟩

However, it will still be useful to have career totals in ready mode because for some players and leagues only totals with no details on the seasons can be known. So we also add to Jordi Alba (Q187159)

⟨ Jordi Alba (Q187159)    ⟩ number of matches played/races/starts (P1350) ⟨ 271 ⟩
of (P642) ⟨ LaLiga (Q324867)    ⟩
date of the first one (P7124) ⟨ 13/09/2009 ⟩
date of the last one Search ⟨ 19/05/2019 ⟩
retrieved (P813) ⟨ 02/07/2019 ⟩

⟨ Jordi Alba (Q187159)    ⟩ total goals in career (P6509) ⟨ 13 ⟩
of (P642) ⟨ LaLiga (Q324867)    ⟩
date of the first one (P7124) ⟨ 11/04/2010 ⟩
date of the last one Search ⟨ 20/04/2019 ⟩
retrieved (P813) ⟨ 02/07/2019 ⟩

⟨ Jordi Alba (Q187159)    ⟩ number of red cards Search ⟨ 3 ⟩
of (P642) ⟨ LaLiga (Q324867)    ⟩
date of the first one (P7124) ⟨ 21/09/2011 ⟩
date of the last one Search ⟨ 25/04/2015 ⟩
retrieved (P813) ⟨ 02/07/2019 ⟩

As for total goals in career (P6509) and number of points/goals/set scored (P1351) uncertainty, on the one hand I can add a national team appearances (P1129) to this discussion (looks like double of number of matches played/races/starts (P1350)), but on the other hand number of points/goals/set scored (P1351) is less specific because there may be goals and points and something else. However, I am ready to agree that the discussing properties can be made more universal by removing the word "career" from their description, but it is necessary to refuse to fill in the statistics through qualifiers, since, returning to the example of Lionel Messi (Q615), we do not know which tournaments are counted here, whether the update dates for goals and red cards match. If there will be separate statistics on LaLiga (Q324867) and on UEFA Champions League (Q18756) (Supercopa de España (Q485997)? International Champions Cup (Q16841334)?) everyone will be able to specify what exactly he puts into the concept of general career statistics by combining options at his own discretion. Сидик из ПТУ (talk) 12:37, 2 July 2019 (UTC)

• By the way, I should note that the both edits Special:Diff/964597314 and Special:Diff/964620741 are incorrect. Career totals are given without any criteria (league? age level?) and National Hockey League (Q1215892) mistakenly duplicated. The more qualifiers league (P118) have, the harder it will be to work with this property. It will be very difficult to track the correctness of the update only for goals if the user did not plan to update the penalty minutes. retrieved (P813) should be independent for different indicators. Сидик из ПТУ (talk) 14:43, 2 July 2019 (UTC)

Community Insights Survey

Share your experience in this survey

Hi LesserJerome,

The Wikimedia Foundation is asking for your feedback in a survey about your experience with Wikidata and Wikimedia. The purpose of this survey is to learn how well the Foundation is supporting your work on wiki and how we can change or improve things in the future. The opinions you share will directly affect the current and future work of the Wikimedia Foundation.

Please take 15 to 25 minutes to give your feedback through this survey. It is available in various languages.

This survey is hosted by a third-party and governed by this privacy statement (in English).

Find more information about this project. Email us if you have any questions, or if you don't want to receive future messages about taking this survey.

Sincerely,

RMaung (WMF) 17:38, 10 September 2019 (UTC)

Reminder: Community Insights Survey

Share your experience in this survey

Hi LesserJerome,

A couple of weeks ago, we invited you to take the Community Insights Survey. It is the Wikimedia Foundation’s annual survey of our global communities. We want to learn how well we support your work on wiki. We are 10% towards our goal for participation. If you have not already taken the survey, you can help us reach our goal! Your voice matters to us.

Please take 15 to 25 minutes to give your feedback through this survey. It is available in various languages.

This survey is hosted by a third-party and governed by this privacy statement (in English).

Find more information about this project. Email us if you have any questions, or if you don't want to receive future messages about taking this survey.

Sincerely,

RMaung (WMF) 19:54, 20 September 2019 (UTC)

Thank you for participating in the FindingGLAMs Challenge!

	Thank you for participating in the FindingGLAMs Challenge!
	With your hard work, you took the 3rd place. Congratulations! By improving information about GLAM institutions on Wikidata, you made the Wikimedia projects better for everyone! Alicia Fagerving (WMSE) (talk) 14:45, 19 March 2020 (UTC)

New OpenRefine reconciliation service

Hi!

Thank you for wearing the {{User loves OpenRefine}} userbox on your user page!

Because the existing Wikidata reconciliation service has had severe performance issues recently, I have created a new one which should be faster and more robust. You can add it to OpenRefine in the reconciliation dialog with the following URL: https://wikidata.reconci.link/en/api (or by replacing en by any other language code).

If you have any issues with this new service, let me know.

Happy reconciling! − Pintoch (talk)