OsamaK
Welcome to Wikidata, OsamaK!
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! --Alaa :)..! 20:41, 14 August 2019 (UTC)
P.S.
editHi! Just a final suggestion: you can subscribe here to the weekly updates about Wikidata, in order to receive a message each week in one of your talk pages, here on Wikidata or in one Wikipedia; it is useful to know new tools and new properties which are proposed or created. It was a pleasure to know you and I hope we will see soon in the future at some other event or in Italy! Good night, --Epìdosis 22:56, 18 August 2019 (UTC)
Adding batches of conflicting qualifiers
editHi there! I see you're adding quickstatement batches of twitter data qualifiers which is great, but retrieved (P813) should not but used as a qualifier and it also makes no sense to have both start time (P580) and point in time (P585) qualifying the same statement. As a human I understand what you're trying to convey (the account start time and the point in time at which number of subscribers is true), but it it makes the actual data conflicting because those qualifiers are both qualifying the main statement and aren't intended to be interpreted that way. It's a known problem in our modelling of twitter data and there's no agreed upon solution currently. --SilentSpike (talk) 12:43, 16 April 2020 (UTC)
- @SilentSpike: Thanks for the great feedback!
- retrieved (P813) was mistakenly added to some items and I will fix it by replacing it with point in time (P585).
- In regard to start time (P580), that qualifier is currently used to mean "date joined" in X username (P2002)'s Wikidata property example (P1855) and it also mentiond as an allowed qualifiers constraint (Q21510851). I can see the confusion if it is interrupted to mean "the start time of the username" or "the start time since the user had that number of subscribers" and this is very relevant to the unresolved discussion on reversing the roles of X username (P2002) and X numeric user ID (P6552). It's fair to note though that we have been adding qualifiers to X username (P2002) to represent the account not the username/subscribers (thinking of has characteristic (P1552), object has role (P3831), end cause (P1534), and even number of subscribers (P3744) itself). The join date shouldn't be an exception. It is clear that we will need to overhaul the Twitter account data representation, but until we do, in my opinion, we should be adding this really useful piece of data especially as these data point might go missing any minute.--OsamaK (talk) 13:32, 16 April 2020 (UTC)
- @OsamaK: Thanks for your well thought out reply. As long as you're aware of the problem then I'm in agreement with you on the data being useful and don't object to you adding these statements. Have considered creating a social media WikiProject in the past as a place to document and develop how we represent various account qualities/data (and why it's done certain ways). The main benefit I see is that a lot of the developments so far are found in fragmented discussions around the place and limited to specific platform identifiers when really the same lessons/knowledge could be applied more generally to all social media data on Wikidata. Never got around to it so far, but perhaps if a few of us are actively interested in improving this data it'd be worth setting that up now. --SilentSpike (talk) 13:52, 16 April 2020 (UTC)
- @SilentSpike: Thank you for raising this! As for the WikiProject, I like it! It sounds like my kind of maintenance work. Let me get back to you on this after a little bit of time. It has been awhile (years!) since I had the chance to spend this much time doing Wikimedia stuff. I feel blessed. Now let me see how long I will manage to keep that rhythm, lol.--OsamaK (talk) 15:13, 16 April 2020 (UTC)
- @OsamaK: Thanks for your well thought out reply. As long as you're aware of the problem then I'm in agreement with you on the data being useful and don't object to you adding these statements. Have considered creating a social media WikiProject in the past as a place to document and develop how we represent various account qualities/data (and why it's done certain ways). The main benefit I see is that a lot of the developments so far are found in fragmented discussions around the place and limited to specific platform identifiers when really the same lessons/knowledge could be applied more generally to all social media data on Wikidata. Never got around to it so far, but perhaps if a few of us are actively interested in improving this data it'd be worth setting that up now. --SilentSpike (talk) 13:52, 16 April 2020 (UTC)
Q19297242
editHello OsamaK. At the moment the Twitter identifier only allows one identical qualifier on Twitter. So when updating the Twitter subscribers the older ones must be replaced. This is not how it is intended, but to change that one has to redefine the identifier. Regards, --Gereon K. (talk) 16:43, 17 April 2020 (UTC)
- @Gereon K.: Thank you for the note! Yes, I will removing the old counts (example) but in a separate process as QuickStatements does not currently allow changing or removing qualifiers. --OsamaK (talk) 17:23, 17 April 2020 (UTC)
- There was some discussion on how to handle this, but I don't think deleting older counts was what is considered the solution. See Wikidata:Property proposal/subscribers. --- Jura 07:16, 20 April 2020 (UTC)
- @Jura1: Thank you for pointing this one out! I have two concerns: (1) almost all existing uses of number of subscribers (P3744) that I have come across don't have point in time (P585) associated with them, leaving them without such a qualifier wouldn't be an option especially with the new qualified data points; (2) in case of a pre-existing point in time (P585) separator, is the proposed approach to repeat the whole Twitter account statement (including start time (P580), end time (P582), has characteristic (P1552), X numeric user ID (P6552), etc) just to document the number of subscribers (P3744) at different point in time (P585)?--OsamaK (talk) 07:35, 20 April 2020 (UTC)
- I think most statements had the date in "retrieved in" not as "point in time". Personally, I don't think (C) is a good idea, even though it was preferred by the participants (not really used since AFAIK). Maybe (I) is the simplest approach. BTW, there was also Wikidata:Requests for permissions/Bot/SilentSpikeBot. --- Jura 07:51, 20 April 2020 (UTC)
- @Jura1: when repeating P580 it shows an "I" warning, so having several different P580 within one identifier is not allowed (even it seems to be a wanted feature). Off course former Twitter names are kept, but old P580s have to be overwritten as it is now. --Gereon K. (talk) 23:05, 21 April 2020 (UTC)
- The idea of (C) is to add several times the same identifier each time with a different point in time/number of subscribers (see File:Example for Jura1.png). Not my proposal BTW. In any case, numbers shouldn't be overwritten or deleted. --- Jura 23:15, 21 April 2020 (UTC)
- @Jura1, Gereon K.: Honestly, this is clearly not applicable. No one should be allowed to contaminate Wikidata with such massive duplication. It even goes against the idea of semantically linked structured data. Eventually, I think, this will require a new-Wikidata-feature kind of solution, aka, "qualifier of qualifier". This will pop up an additional "dimension" that allows time-based serial data points for the same qualifier to be documnted. Meanwhile, I really do not see that the number of supporters of (C) constitute any meaningful consensus especially when taken in the context of other related discussions. --OsamaK (talk) 07:45, 22 April 2020 (UTC)
- Exactly. The figures change every day. Do we really want to have 3650 entries in a 10 year period? You won't find anything in the items anymore and they will have so many bytes that you cannot open them any more. It is already very trying with the FIDE rating that gets added with a new rating number every month (for a period since 1970). --Gereon K. (talk) 08:09, 22 April 2020 (UTC)
- Personally, I still like (A) and (D1). (I) seems unproblematic too. IMHO, they are surely more important than posthumous FIDE ratings. --- Jura 08:42, 22 April 2020 (UTC)
- Shall we delete all pages of deceased persons or how can I interpret your remark about posthumous FIDE ratings? The benefit of ratings of deceased persons can be found for example here: de:Viktor Kortschnoi. --Gereon K. (talk) 10:07, 22 April 2020 (UTC)
- With posthumous I mean ELO ratings for dates after a person's death. Which part of that article or graphic there do you refer to? --- Jura 10:26, 22 April 2020 (UTC)
- There are no ELO ratings after the deatch of a person, unless a tournament the person played has not been rated yet, and since the ratings are monthly now this happens quite fast. I was talking about the ELO diagram at the bottom of the chapter "Leben": de:Viktor Kortschnoi#Leben. --Gereon K. (talk) 10:40, 22 April 2020 (UTC)
- This would be a posthumous rating (five years after the death). Maybe that problem has been fixed since. No problem with ratings during the livetime. --- Jura 10:53, 22 April 2020 (UTC)
- That of course was nonsense. I fixed that. --Gereon K. (talk) 11:19, 22 April 2020 (UTC)
- This would be a posthumous rating (five years after the death). Maybe that problem has been fixed since. No problem with ratings during the livetime. --- Jura 10:53, 22 April 2020 (UTC)
- Sample change for version (I.): [1] --- Jura 15:34, 22 April 2020 (UTC)
- In your sample case we have the warning "citation needed constraint. Statements for number of subscribers should have at least one reference." now. What are we going to do about that? --Gereon K. (talk) 08:42, 23 April 2020 (UTC)
- It's just a suggestion constraint .. Maybe we should continue this discussion elsewhere .. --- Jura 09:09, 24 April 2020 (UTC)
- In your sample case we have the warning "citation needed constraint. Statements for number of subscribers should have at least one reference." now. What are we going to do about that? --Gereon K. (talk) 08:42, 23 April 2020 (UTC)
- There are no ELO ratings after the deatch of a person, unless a tournament the person played has not been rated yet, and since the ratings are monthly now this happens quite fast. I was talking about the ELO diagram at the bottom of the chapter "Leben": de:Viktor Kortschnoi#Leben. --Gereon K. (talk) 10:40, 22 April 2020 (UTC)
- With posthumous I mean ELO ratings for dates after a person's death. Which part of that article or graphic there do you refer to? --- Jura 10:26, 22 April 2020 (UTC)
- Shall we delete all pages of deceased persons or how can I interpret your remark about posthumous FIDE ratings? The benefit of ratings of deceased persons can be found for example here: de:Viktor Kortschnoi. --Gereon K. (talk) 10:07, 22 April 2020 (UTC)
- Personally, I still like (A) and (D1). (I) seems unproblematic too. IMHO, they are surely more important than posthumous FIDE ratings. --- Jura 08:42, 22 April 2020 (UTC)
- Exactly. The figures change every day. Do we really want to have 3650 entries in a 10 year period? You won't find anything in the items anymore and they will have so many bytes that you cannot open them any more. It is already very trying with the FIDE rating that gets added with a new rating number every month (for a period since 1970). --Gereon K. (talk) 08:09, 22 April 2020 (UTC)
- @Jura1, Gereon K.: Honestly, this is clearly not applicable. No one should be allowed to contaminate Wikidata with such massive duplication. It even goes against the idea of semantically linked structured data. Eventually, I think, this will require a new-Wikidata-feature kind of solution, aka, "qualifier of qualifier". This will pop up an additional "dimension" that allows time-based serial data points for the same qualifier to be documnted. Meanwhile, I really do not see that the number of supporters of (C) constitute any meaningful consensus especially when taken in the context of other related discussions. --OsamaK (talk) 07:45, 22 April 2020 (UTC)
- The idea of (C) is to add several times the same identifier each time with a different point in time/number of subscribers (see File:Example for Jura1.png). Not my proposal BTW. In any case, numbers shouldn't be overwritten or deleted. --- Jura 23:15, 21 April 2020 (UTC)
- @Jura1: when repeating P580 it shows an "I" warning, so having several different P580 within one identifier is not allowed (even it seems to be a wanted feature). Off course former Twitter names are kept, but old P580s have to be overwritten as it is now. --Gereon K. (talk) 23:05, 21 April 2020 (UTC)
- I think most statements had the date in "retrieved in" not as "point in time". Personally, I don't think (C) is a good idea, even though it was preferred by the participants (not really used since AFAIK). Maybe (I) is the simplest approach. BTW, there was also Wikidata:Requests for permissions/Bot/SilentSpikeBot. --- Jura 07:51, 20 April 2020 (UTC)
- @Jura1: Thank you for pointing this one out! I have two concerns: (1) almost all existing uses of number of subscribers (P3744) that I have come across don't have point in time (P585) associated with them, leaving them without such a qualifier wouldn't be an option especially with the new qualified data points; (2) in case of a pre-existing point in time (P585) separator, is the proposed approach to repeat the whole Twitter account statement (including start time (P580), end time (P582), has characteristic (P1552), X numeric user ID (P6552), etc) just to document the number of subscribers (P3744) at different point in time (P585)?--OsamaK (talk) 07:35, 20 April 2020 (UTC)
"Remove obsolete count"
editI saw you making a bunch of edits removing twitter follower numbers today. I don't think it's important data, so I don't object, but in general it's better to mark the values as deprecated rather than removing them. Thanks. Mike Peel (talk) 15:33, 3 May 2020 (UTC)
- @Mike Peel: Thank you for the heads up! I see that we can mark statements as deprecated but not qualifiers. It would be great if we can mark a qualifier as deprecated, and even greater if we can add a qualifier to some given qualifier (e.g. to mark the point in time in which the number of followers was valid), but unfortunately, neither of these two workarounds are currently applicable. It seems that removing obsolete counts is the only clean solution until a more radical solution to the way we structure these kinds of data is finally applied, does this make sense?--OsamaK (talk) 16:19, 3 May 2020 (UTC)
- Ah, good points, fair enough. Thanks. Mike Peel (talk) 16:27, 3 May 2020 (UTC)
- I object to the removing of follower numbers. With point in time they are never obsolete, just as recent as possible, until someone comes and updates the numbers. I think this is completely valid. --Gereon K. (talk) 20:27, 4 May 2020 (UTC)
- @Gereon K.: The problem is that we cannot qualify different number of subscribers (P3744) values (which are, themselves, used as qualifiers). point in time (P585) can only be applied to the whole X username (P2002). It's an inherent deficiency in the way the data are allowed to be represented.--OsamaK (talk) 20:38, 4 May 2020 (UTC)
- I object to the removing of follower numbers. With point in time they are never obsolete, just as recent as possible, until someone comes and updates the numbers. I think this is completely valid. --Gereon K. (talk) 20:27, 4 May 2020 (UTC)
- Ah, good points, fair enough. Thanks. Mike Peel (talk) 16:27, 3 May 2020 (UTC)
- Why is the idea of most recent not allowed? We have the most recent names of renamed objects and people, we have the most recent professions, the most recent wikilink after name changes of Wikipedia article. The qualifier "number of subsribers" exists. This qualifier only makes sense with the number of qualifiers, and this changes alomst every day in the first place. As long as "number of qualifiers" exists it can be used. --Gereon K. (talk) 20:45, 4 May 2020 (UTC)
- @Gereon K.: Ah! I see what you mean. You're referring to instances when number of subscribers (P3744) was removed all together. True, there has been very few instances in which the number of subscribers (P3744) added by the QuickStatements batch changed by the time it was checked for "duplication" (e.g.), so the new number was removed assuming that the number of subscribers (P3744) just added by QuickStatements still exists. I will fix this. From now on, it will ensure that before removing an "alien" number of subscribers (P3744) qualifier, even if it is different from the batch just added by QuickStatements, a recent number of subscribers (P3744) must exist.--OsamaK (talk) 21:35, 4 May 2020 (UTC)
- @Gereon K.: I just discovered another issue: in the more recent edits, apparently, the Twitter user IDs and number of subscribers were never updated! It seems that there was some missed batch of QuickStatements. I will fix that before removing "obsolete counts". Thanks for the heads up, Gereon.--OsamaK (talk) 21:48, 4 May 2020 (UTC)
- Currently running batch #33518 and batch #33521 which will add the missed Twitter data.--OsamaK (talk) 22:00, 4 May 2020 (UTC)
- Why is the idea of most recent not allowed? We have the most recent names of renamed objects and people, we have the most recent professions, the most recent wikilink after name changes of Wikipedia article. The qualifier "number of subsribers" exists. This qualifier only makes sense with the number of qualifiers, and this changes alomst every day in the first place. As long as "number of qualifiers" exists it can be used. --Gereon K. (talk) 20:45, 4 May 2020 (UTC)
2020-05 P2002
editThank you for improving X username (P2002). Visite fortuitement prolongée (talk) 10:08, 10 May 2020 (UTC)
couls you please use NSFW subreddit (Q83807365) onstead?--Trade (talk) 15:25, 8 July 2020 (UTC)
- Thank you Trade for pointing this out! I am wondering: what's the rule here? I see that we are using verified account or profile (Q28378282) across the different platforms instead of having a platform-specific value, why should this be different?--OsamaK (talk) 16:48, 8 July 2020 (UTC)
- not safe for work is a far more vague item. It can pretty much mean anything from an account to a YouTube video.
You also might wanna be aware of the different YouTube qualities
We sent you an e-mail
editHello OsamaK,
Really sorry for the inconvenience. This is a gentle note to request that you check your email. We sent you a message titled "The Community Insights survey is coming!". If you have questions, email surveys@wikimedia.org.
You can see my explanation here.
MediaWiki message delivery (talk) 18:46, 25 September 2020 (UTC)