LiberatorG

Hi, thanks for helping to revert vandalism. Would you like rollback permissions so you can do it a bit quicker? See WD:ROLLBACK for info on the right; if you do, then let me know and I'll flag your account.

Regards, -- Ajraddatz (talk) 22:12, 5 August 2019 (UTC)Reply

@Ajraddatz: Sure, that would be helpful. Thanks! -LiberatorG (talk) 22:24, 5 August 2019 (UTC)Reply

No problem, thanks for helping out. :-) -- Ajraddatz (talk) 22:25, 5 August 2019 (UTC)Reply

Thanks for helping me clean up after the mistakes i made using QuickStatements. --Trade (talk) 15:28, 17 August 2020 (UTC)Reply

No problem! –LiberatorG (talk) 15:41, 17 August 2020 (UTC)Reply

On the site https://commons.wikimedia.org/wiki/Category:Connie_Francis I changed Connie Francis' wrong birth year from 1938 to 1937. Why did you reverse that?

Rolf

@‎Rolf Niepraschk: I reverted it because the statement references say 1938:

* https://snaccooperative.org/ark:/99166/w6554v2v

* https://www.britannica.com/biography/Connie-Francis

* https://www.munzinger.de/search/go/document.jsp?id=00000010211

However, I just checked the English Wikipedia article and I see that it gives a different reference https://www.burlingtoncountytimes.com/entertainmentlife/20171210/tinseltown-talks-roller-coaster-life-of-connie-francis that says 1937. Since there are conflicting references, the way to enter that would be as an additional date of birth (P569) statement with the other date, each with their own separate references that state that date, and if there is strong evidence that one of the dates is incorrect then that statement should be marked deprecated with a reason for deprecated rank (P2241) qualifier (see Help:Deprecation). It is never correct to have the statement state one date but the references on that statement state a different date. –LiberatorG (talk) 13:07, 26 September 2020 (UTC)Reply

Hello LiberatorG,
I saw you posting a last warning on User_talk:82.79.62.243. Nothing has changed since your message because this user simply doesn't comply. Is there any change to apply a global block of a whole IP range to stop this person?

This issue is going on for several months now - not just in Wikidata but globally: WD, Commons, en.wp, it.wp, ro.wp, fr.wp and almost everywhere. It's not just this one IP but also several others were used in the past. User:Gikü and me have checked and reverted many edits.

Here is my last request including a list of IP's whose contributions strongly appear to be from the same person: Wikidata:Administrators'_noticeboard/Archive/2020/09#continous_disruptive_editing_of_one_user_under_various_IPs

I'm really tired of this issue. But what can you do when you are a normal user?

Best regards --Zaccarias (talk) 17:43, 13 October 2020 (UTC)Reply

@Zaccarias:: Hi Zaccarias, for persistent Wikidata vandalism I would normally make a request at Wikidata:Administrators' noticeboard. If they've already been blocked on individual sites and you want to request a global block of the IP address or range, see meta:Global blocks. –LiberatorG (talk) 19:33, 13 October 2020 (UTC)Reply

As you can see I already have used the local administrators' noticeboard. It seems difficult to reach someone there who will deal with the problem. Therefore, I doubt it is worth the time to create a detailed block request. I will try again sometime.--Zaccarias (talk) 20:05, 13 October 2020 (UTC)Reply

Thank you for telling me the links. User is blocked, global block hopefully underway. Sorry I took you for an admin by mistake (because you posted that final warning on the IP's talkpage.) --Zaccarias (talk) 21:17, 14 October 2020 (UTC)Reply

Did you start to undo the edits I made like the others? Look, I told the others, but I'll tell you. Don't undo my edits if you don't know the Turkish spelling rules. Because I am doing it according to Turkish spelling rules. Have a nice day!  – The preceding unsigned comment was added by Doğru Tercüman (talk • contribs) at 16:20, 2 February 2021 (UTC).Reply

@Doğru Tercüman: The Turkish capitalization rules are listed at [1]; can you please tell me which one you think justifies capitalizing nouns that are not proper nouns, such as cinsiyet and bacak? Also please remember to sign your comments with ~~~~. Thanks! –LiberatorG (talk) 17:18, 2 February 2021 (UTC)Reply

First of all, don't get involved because you don't know the Turkish spelling rules. Here are the links.https://www.tdk.gov.tr/icerik/yazim-kurallari/buyuk-harflerin-kullanildigi-yerler/ https://www.tdk.gov.tr/icerik/yazim-kurallari/noktalama-isaretleri-aciklamalar/ You don't know Turkish though, how will you read? This is one of the questions I have in mind.  – The preceding unsigned comment was added by Doğru Tercüman (talk • contribs) at 07:28, 3 February 2021 (UTC).Reply

@Doğru Tercüman: This is about your capitalization in edits such as Special:Diff/1353676415. You are repeating the same link that I already posted to you above, so I am familiar with it. Which of the rules from that page do you think justifies capitalization of something that is not a sentence, poetry, proper noun, specific date, sign, title, or caption? Also I again ask that you please remember to sign your comments with ~~~~. Thanks. –LiberatorG (talk) 11:14, 3 February 2021 (UTC)Reply

Thx a lot for detecting wrong uses of Patrinum ID (P9113).
It was my mistake. I built QS commands based on fr.wikipedia links used by Patrinum. And some of them are wrong... :-(
-- Bargioni 🗣 10:34, 9 February 2021 (UTC)Reply

@Bargioni: I reverted the obvious errors (such as P9113 on disambiguation pages), but I will need you to fix the remaining errors. –LiberatorG (talk) 10:47, 9 February 2021 (UTC)Reply

@LiberatorG: Thx again. I'll try to discover more errors. -- Bargioni 🗣 10:50, 9 February 2021 (UTC)Reply

Hi. re [2] etc:

You are wrong. Yes, Commission on Isotopic Abundances and Atomic Weights (Q15647945) (CIAAW) uses the old-fashioned phrase "standard atomic weight (Q28912964)" but actually publishes a true relative atomic mass (Q41377). By definition, when per chemical element &tc, this is a mass.

The real problem is that Wikidata mass (P2067) does not recognise relative mass (ie, no unit). That is for Wikidata to solve. Not for editors to change the sourced value.

You are invited to understand this issue. -DePiep (talk) 20:58, 3 November 2021 (UTC)Reply

@DePiep: Hi, thanks for discussing this. I only mentioned the atomic weight vs. mass distinction because the source itself makes that distinction, and your basis for making your change was the units used by the source. But the source itself uses units of dalton for atomic mass. So even if we look only at this source, atomic mass should have dalton units. But the real reason that a unit is needed is because Wikidata consensus is that mass (P2067) represents mass (not relative atomic mass) and requires a unit, and the property constraints that were created based on this consensus require this. As a practical matter, the same property is used on a variety of items and so it is necessary that it have a consistent meaning that does not vary depending on the kind of item. It is my understanding that the dalton unit allows a trivial conversion of relative atomic mass to mass, and therefore allows the relative atomic mass to be represented using the mass property with this unit. However if for some reason that does not work, and relative atomic mass is required and it cannot be converted to a mass, then another property is needed for this. It cannot use mass (P2067) which already has its own meaning. –LiberatorG (talk) 21:34, 3 November 2021 (UTC)Reply

No. (later more) -DePiep (talk) 21:35, 3 November 2021 (UTC)Reply

Simple rule 1: if mass (P2067) cannot/shouldnot/willnot handle correct, wellsourced mass values, then do WD change P2067. Or add Pxxx "relative mass". -DePiep (talk) 21:43, 3 November 2021 (UTC)Reply

Simple rule 0: if the source says "no unit" (ie, relative value; no unit at all), then Wikidata should honour that. DePiep (talk) 22:10, 3 November 2021 (UTC)Reply

@DePiep: There needs to be a way to distinguish relative atomic mass values from absolute mass values that are used with this property on all other types of items. If the dalton unit cannot be used to make this distinction, then a different property would be needed. I don't understand your objection to using the dalton unit; can you help me understand your objection to this unit? There should be no issue with trivial conversions of notation, including converting between "atomic weight", "relative atomic mass", or "mass in daltons". Wikidata does not require that the text be copied verbatim from the source, as long as the conversion is trivial and is not disputed. For example, if an original source is discussing an event that occurred in 2001 and then says "on January 21 of the following year", there is no issue with representing that in Wikidata as 2002-01-21 Gregorian even though the year 2002 does not occur in the original text and the month is not referred to using a number and the Gregorian calendar was only implied. Similarly if a source provides values in roman numerals there is no issue converting them to regular Arabic numbers as used on Wikidata. Such conversions are appropriate and allow all values of the property to be treated consistently. Are you disputing that "relative atomic mass", "atomic weight", and "mass in daltons" are equivalent, or do you agree that they are equivalent but believe that the conversion between them is nontrivial, or do you have some other objection to the policy? If we had a property called "relative atomic mass" that used a unitless number, and there was a source that provided the mass in daltons, or provided the "atomic weight", would you object to adding that number to the "relative atomic mass" property? –LiberatorG (talk) 23:29, 3 November 2021 (UTC)Reply

Question 0: where does the source say that: [3]? Or point me to the Da in [4]?. -DePiep (talk) 22:25, 3 November 2021 (UTC)Reply

If you are referring to my edit comment in Special:Diff/1521726638, it is a quote from section 1.1 of [5]. The same document also provides [6] as a reference, and says in section 8 footnote c, "Atomic masses of nuclides are expressed in daltons (symbol, Da)". -LiberatorG (talk) 23:29, 3 November 2021 (UTC)Reply

No. My "Question 0" link is fine. -DePiep (talk) 00:06, 4 November 2021 (UTC)Reply

Hello! Thank you for linking that page about descriptions. I used the Wikipedia:Shortdesc helper, which states that "capitalising the first letter," which is corroborated by Wikipedia:Short_description#SDFORMAT, stating "start with a capital letter."

I do see how your link on Wikidata here Help:Description#Capitalization clearly states the opposite, i.e. not capitalizing. So, should these always be mismatched? i.e. lowercase on Wikidata, but capitalized on Wikipedia? This seems like it would cause much confusion, especially with the ability to import and directly export from Shortdesc helper when checking maintenance categories. Top5a (talk) 16:47, 9 April 2022 (UTC)Reply

This may also be of interest to you: Wikipedia:MediaWiki:Gadget-Shortdesc-helper.js#L-743

I am just stating why my changes were made as such; I genuinely do not know what the consensus is between the Wikipedia and Wikidata projects, but am rather alerting you as to why you might see these types of edits occurring. Top5a (talk) 17:20, 9 April 2022 (UTC)Reply

@Top5a: Yes, the descriptions on Wikidata and English Wikipedia have different purposes and different policies. The policies have already been discussed extensively on the respective projects and seem unlikely to change. I haven't used the Shortdesc helper gadget, but it looks like the code that you pointed to takes the description that it just added to Wikidata (or obtained from Wikidata), and is then uppercasing the first letter before adding it to Wikipedia. So apparently that allows a single description to be entered and the script will take care of this difference in policy for you as long as the entered description is compliant with the Wikidata policies. If the description begins with a proper noun then both descriptions should be the same. I hope that helps. –LiberatorG (talk) 17:54, 9 April 2022 (UTC)Reply

Thank you for this information. While your statement appears true, the extant issue, as far as I understand it, is that the shortdesc helper by default (the force capitalization is within a !isLocal if statement) will automatically export the capitalized version to Wikidata (especially if Wikidata does not have a prior entry), so people using the tool will erroneously be pushing capitalized shortdescs to Wikidata, in conflict with Wikidata's policies, and be none the wiser. Wikipedia:Category:Short_description_matches_Wikidata, however, does correctly perform a case-insensitive check when populating. I will notify the maintainer on the tool's talk page to perhaps add a second textfield when exporting to Wikidata, such that the editor may set the correct capitalization prior to export. Thank you! Top5a (talk) 18:07, 9 April 2022 (UTC)Reply

Hello! Can you add hr:Sveučilište u Chicagu to Q131252? Somehow I can not do it. --Čeljust (talk) 11:31, 26 April 2022 (UTC)Reply

It looks like User:Dean72 has just added it. –LiberatorG (talk) 15:13, 26 April 2022 (UTC)Reply

thanks him! Can someone also add hr:Web-sajt to Q35127. There is also some error when I try to do it. Čeljust (talk) 16:17, 26 April 2022 (UTC)Reply

Done. –LiberatorG (talk) 16:29, 26 April 2022 (UTC)Reply

I saw you reverted my addition of protocol to source code repository. I thought this was different information from version control system and web interface software.

A Git repository link on Github for example, can be for use with HTTPS, SSH, or Git protocols. The discussion on the talk page seems to imply this is redundant because the protocol is in the URL, but I do not see how that is the case when there is utility in linking to the item for the protocol. For example, if the link has the protocol as SSH, you would be able to get information about what software is necessary to pull the SSH link for example, rather than rely on accounting for every possible string combination. --Middle river exports (talk) 00:25, 12 May 2022 (UTC)Reply

@Middle river exports: The source code repository URL (P1324) property value is a URL, and originally the protocol (P2700) qualifier on source code repository URL (P1324) was documented as the way to specify the version control system that the URL could be used with. However, the usage of this was a mess as it was mandatory but people didn't know what to put there; later the version control system (P8423) qualifier was created to replace it. A https: URL such as "https://github.com/foo/bar" always uses https and cannot be used with ssh; a different URL would be required for ssh. There is no issue with having multiple URLs listed, e.g. a https: URL, a ssh: URL, and even an (obsolete) git: URL (although github and most sites don't support git: URLs any more); the protocol that is part of the URL is the protocol that would be used to access that URL. If version control system (P8423) = Git (Q186055) then that means that the user can pass the URL to a git command like "git clone URL" and it should work; if they care about the whether git is using https or ssh, for example, they can see that from the URL prefix. It is the same with URLs elsewhere on Wikidata, such as official website (P856), official blog URL (P1581), or issue tracker URL (P1401); we do not add a separate qualifier to indicate that it uses https. –LiberatorG (talk) 00:57, 12 May 2022 (UTC)Reply

I guess, but I don't quite see it as the same. You could have source code on an FTP server for example that is not version controlled. It also seems weird to assume the client a data consumer would be using to access the information through the same software or procedure. The reason to specify an SSH protocol would be most likely to pull from repositories that use different version control systems from each other, rather than passing it to a git client. Protocol could be used as a criterion to filter out source code repositories (or filter for them).

Metadata related to the protocol itself also has more clear of a utility for source code repositories than it does for official website. Lets say you had a svn+ssh:// URL and you wanted to use the protocol property to tie it to both the SVN and the SSH protocols for this "tunnel" protocol. End users of official website are much less likely to be dealing with URLs in that way. --Middle river exports (talk) 01:22, 12 May 2022 (UTC)Reply

@Middle river exports: If the URL can be passed to a version control system, version control system (P8423) specifies the version control system; otherwise version control system (P8423) should be set to novalue. If the URL has a web interface (intended for humans using it from a web browser) then the web interface software (P10627) qualifier is used to indicate that, or it should be novalue if it has no such web interface. For a https GitHub repository URL, version control system (P8423) = Git (Q186055) and web interface software (P10627) = GitHub (Q364) since the same URL works in git commands and in a web browser, and so the URL can be used with any client that supports either a Git repository URL OR a human-readable web page (such as a web browser). If the URL works in git commands but has no such web interface then version control system (P8423) = Git (Q186055) and web interface software (P10627) = novalue; in this case the URL can be used with any software that accepts a Git repository URL, and there is no assumption that a particular client is used, but a client that doesn't know about Git repositories isn't likely going to be able to get to the source code using such a URL since it would have to know which paths to access under that and Git's internal formats. If there is no source code repository but there are downloadable files for each version, the download URL (P4945) qualifier should be used instead on individual software version identifier (P348) statements. –LiberatorG (talk) 02:21, 12 May 2022 (UTC)Reply

You added web interface software (P10627) = no value to http://hg.code.sf.net repository statements, e.g. with this edit. However, these repositories do provide a web interface—you just need to make sure that your browser doesn't redirect you to the HTTPS version. I never used Mercurial but I think these repositories use hgweb (Q112183167). So should I change the qualifier's value from no value to hgweb (Q112183167)? Dexxor (talk) 08:18, 31 May 2022 (UTC)Reply

@Dexxor: Thanks for finding that. Indeed my browser redirects to https, and if I disable that then a web interface is shown. So yes, it looks like these those 25 statements should be updated; feel free to change them, or I can change them later if you don't do it first. As browsers increasingly redirect to https by default it may not be the best URL for those that want a web interface, however. It would probably be a good idea to add the SourceForge web interface (e.g. https://sourceforge.net/p/narocad/narocad/) as an additional P1324 statement if not already present, although unfortunately those URLs don't work with hg commands. –LiberatorG (talk) 11:16, 31 May 2022 (UTC)Reply

I added the statement "indigenous to" because barbecue returns errors in "culture" statement. Could you please help me resolve the errors? Thanks--Carnby (talk) 04:40, 4 June 2022 (UTC)Reply

@Carnby: I replied to this at Talk:Q30#Barbecue:_statement_culture:_United_States_of_America_should_have_a_statement_indigenous_to.. –LiberatorG (talk) 16:12, 4 June 2022 (UTC)Reply

Hi, I am new to Wikidata and I added the version 1.30.0 to mpg123, but I did not find the way to make this version the one with a "preferred rank". Can you tell me how you changed that? Thanks in Advance Firequarky (talk) 13:51, 29 June 2022 (UTC)Reply

@Firequarky: Thanks for adding the new software version. When editing a statement, the rank can be set using the small blue icon to the left of the value. More details can be found at Help:Ranking#How_to_apply_ranks. –LiberatorG (talk) 14:23, 29 June 2022 (UTC)Reply

Hi, I am quite new on Wikidata and I emptied file format "Snagit Profile: .snagprof" because it is no more in use since Snagit (Windows) version 12 (year 2015) and it has never been used in Snagit (Mac). You reverted my recent edit and now this totally outdated file format shows up twice in the "Software Infobox" on (Catalan Wikipedia) https://ca.wikipedia.org/wiki/Snagit. How can I get rid of https://www.wikidata.org/wiki/Q105852741? Thanks in advance for your help. Antoine Legrand (talk) 21:54, 29 June 2022 (UTC)Reply

@Antoine Legrand: Wikidata is not only for data about things that currently exist or products that are currently sold, but also for historical data. When a person dies or a product is not longer sold or a file format is no longer supported by the most recent version of a product, the corresponding item should not be blanked. Even if the item is completely invalid the item should not be blanked (the proper procedure in that case is to propose deletion of the item on Wikidata:Requests_for_deletions, but that is not the case here). If a particular application was changed to no longer read or write this file format then that is indicated by adding an end time (P582) qualifier to the readable file format (P1072) or writable file format (P1073) statement on the software item. If you know the year that support for this was removed then use that as the value of the end time (P582) qualifier; if you have no idea then the value can be set to unknown value. I'm not familiar with the cawiki template to know if that is sufficient to remove it from the cawiki infobox. –LiberatorG (talk) 22:32, 29 June 2022 (UTC)Reply

Is split between several Git repositories; it is not a project lacking version control. --Middle river exports (talk) 00:03, 4 July 2022 (UTC)Reply

Now, if you wanted to be pedantic, you could add the 136 Git repositories which make up GrapheneOS separately, but this would be a waste of time when these can be referred to under a single link. A single project page on GitHub can include multiple nested Git repositories, or even have repositories with other version control systems within it, so if we were to interpret the version control system property as referring to the version control system of something other than the project like the URL (?) it would render the property information-less. Middle river exports (talk) 00:10, 4 July 2022 (UTC)Reply

@Middle river exports: Yes the project uses version control. I also have no objection to listing just the GitHub user page instead of each of the Git repositories individually. But version control system (P8423) is not a property of the item, it is a qualifier on the URL, and that URL can't be git cloned as it is not a Git repository. A web page that isn't a Git repository is fine as long as the qualifiers are accurate about what it is. –LiberatorG (talk) 00:21, 4 July 2022 (UTC)Reply

I'm skeptical of the purpose of modelling it that way, but I've updated the property to point to the manifest file repository which can be used to clone the entire contents of the project at once as this is usable under this notion of the version control system property. --Middle river exports (talk) 00:35, 4 July 2022 (UTC)Reply

Ok, sounds good. –LiberatorG (talk) 00:41, 4 July 2022 (UTC)Reply

At the GrapheneOS article there has been recent "confusion" over who is involved in GrapheneOS at GitHub. I think it could be fake confusion, but regardless, that is why I thought linking to the "top level" of the project for the Infobox would be better. I would welcome any suggestions for how to make the Infobox more clear and idiot proof. Thanks. -- Yae4 (talk) 19:19, 6 July 2022 (UTC)Reply

@Yae4: I'm not sure what you mean. There is already a GitHub username (P2037) statement that links to the GitHub organization. If it clarifies things in some way I have no objection to also linking to it in a new source code repository URL (P1324) statement with a version control system (P8423) qualifier of no value; my objection was because you changed the URL in the existing statement but the existing qualifiers relate to the previous URL and do not apply to your URL. –LiberatorG (talk) 23:16, 6 July 2022 (UTC)Reply

There's a problem in cheesecake (Q215348): conflicts-with constraint - An entity should not have statements for both Google Knowledge Graph ID and Freebase ID.--Carnby (talk) 07:29, 18 July 2022 (UTC)Reply

@Carnby: If this particular Freebase ID was replaced by a Google Knowledge Graph ID and is no longer valid, then the statement could be marked with an end time (P582) qualifier or with deprecated rank (but should not be removed). In this case, however, it appears that the Freebase ID is valid; both https://www.google.com/search?kgmid=/m/02mg4z and https://angryloki.github.io/mreid-resolver/#/m/02mg4z are working. –LiberatorG (talk) 07:58, 18 July 2022 (UTC)Reply

I solved the issue specifying an exception in Google Knowledge Graph ID (P2671)--Carnby (talk) 08:26, 18 July 2022 (UTC)Reply

Dear LiberatorG,

I hope you are doing good,

I am Kholoud, a researcher at King's College London, and I work on a project as part of my PhD research, in which I have developed a personalised recommender system that suggests Wikidata items for the editors based on their past edits. I am inviting you to a task-based study that will ask you to provide your judgments about the relevance of the items suggested by our system based on your previous edits. Participation is completely voluntary, and your cooperation will enable us to evaluate the accuracy of the recommender system in suggesting relevant items to you. We will analyse the results anonymised, and they will be published to a research venue. The study will start in late January 2022 or early February 2022, and it should take no more than 30 minutes.

If you agree to participate in this study, please either contact me at kholoud.alghamdi@kcl.ac.uk or use this form https://docs.google.com/forms/d/e/1FAIpQLSees9WzFXR0Vl3mHLkZCaByeFHRrBy51kBca53euq9nt3XWog/viewform?usp=sf_link I will contact you with the link to start the study.

For more information about the study, please read this post: https://www.wikidata.org/wiki/User:Kholoudsaa In case you have further questions or require more information, don't hesitate to contact me through my mentioned email.

Thank you for considering taking part in this research. Regards Kholoudsaa (talk) 15:44, 13 December 2022 (UTC)Reply

Concerning 1789467735: Thanks for the heads-up. I'd suggest removing or deprecating Property:P31#P31$dfcd1afa-480c-29ea-b775-7a35b968f73e. Nw520 (talk) 23:53, 13 December 2022 (UTC)Reply

Hello, could you explain why you reverted my additions to source code repository URL (P1324) to add Hugging Face repos as aliases?

All models, data sets, and spaces on Hugging Face Hub are valid git repositories and are valid for reference with source code repository URL (P1324). Keplersj (talk) 22:49, 14 March 2024 (UTC)Reply

Sure. The source code repository URL (P1324) property is independent of the version control system, project, or hub. It is already questionable that there are aliases specific to several popular version control systems; it is certainly not reasonable to add aliases for individual projects or hubs. That would be like adding an alias for official website (P856) specific to individual hosting sites. The URL can obviously reference any site. LiberatorG (talk) 22:56, 14 March 2024 (UTC)Reply

If it is not reasonable to add aliases for individual projects or hubs, why keep the GitHub, Bitbucket, GitLab, and SourceForge aliases?

If we're going to follow this logic let's at least be consistent. Keplersj (talk) 23:01, 14 March 2024 (UTC)Reply

I didn't see those but I agree that those shouldn't be there either. It looks like all four of those were added in the same change in 2021. An alias for GitHub repository or maybe even Sourceforge repository might be justifiable just because some people use that interchangeably with source code repository since those were the first popular hubs, but those using newer hubs know that it is just one of many hubs and that the URL is what identifies it as being on a particular hub. -LiberatorG (talk) 23:35, 14 March 2024 (UTC)Reply