Daniel Kinzler (WMDE)

Changing username

Hello and Sat Sri Akaal! I don't know the where to request so writing here. I'm changing my username globally to "itarbuttar" as per the meta request. Please check to verify and rename and oblige. Thanks a lot. --TariButtar (talk) 14:13, 7 November 2012 (UTC)

An important message about renaming users

Dear Daniel Kinzler (WMDE),

I am cross-posting this message to many places to make sure everyone who is a Wikimedia Foundation project bureaucrat receives a copy. If you are a bureaucrat on more than one wiki, you will receive this message on each wiki where you are a bureaucrat.

As you may have seen, work to perform the Wikimedia cluster-wide single-user login finalisation (SUL finalisation) is taking place. This may potentially effect your work as a local bureaucrat, so please read this message carefully.

Why is this happening? As currently stated at the global rename policy, a global account is a name linked to a single user across all Wikimedia wikis, with local accounts unified into a global collection. Previously, the only way to rename a unified user was to individually rename every local account. This was an extremely difficult and time-consuming task, both for stewards and for the users who had to initiate discussions with local bureaucrats (who perform local renames to date) on every wiki with available bureaucrats. The process took a very long time, since it's difficult to coordinate crosswiki renames among the projects and bureaucrats involved in individual projects.

The SUL finalisation will be taking place in stages, and one of the first stages will be to turn off Special:RenameUser locally. This needs to be done as soon as possible, on advice and input from Stewards and engineers for the project, so that no more accounts that are unified globally are broken by a local rename to usurp the global account name. Once this is done, the process of global name unification can begin. The date that has been chosen to turn off local renaming and shift over to entirely global renaming is 15 September 2014, or three weeks time from now. In place of local renames is a new tool, hosted on Meta, that allows for global renames on all wikis where the name is not registered will be deployed.

Your help is greatly needed during this process and going forward in the future if, as a bureaucrat, renaming users is something that you do or have an interest in participating in. The Wikimedia Stewards have set up, and are in charge of, a new community usergroup on Meta in order to share knowledge and work together on renaming accounts globally, called Global renamers. Stewards are in the process of creating documentation to help global renamers to get used to and learn more about global accounts and tools and Meta in general as well as the application format. As transparency is a valuable thing in our movement, the Stewards would like to have at least a brief public application period. If you are an experienced renamer as a local bureaucrat, the process of becoming a part of this group could take as little as 24 hours to complete. You, as a bureaucrat, should be able to apply for the global renamer right on Meta by the requests for global permissions page on 1 September, a week from now.

In the meantime please update your local page where users request renames to reflect this move to global renaming, and if there is a rename request and the user has edited more than one wiki with the name, please send them to the request page for a global rename.

Stewards greatly appreciate the trust local communities have in you and want to make this transition as easy as possible so that the two groups can start working together to ensure everyone has a unique login identity across Wikimedia projects. Completing this project will allow for long-desired universal tools like a global watchlist, global notifications and many, many more features to make work easier.

If you have any questions, comments or concerns about the SUL finalisation, read over the Help:Unified login page on Meta and leave a note on the talk page there, or on the talk page for global renamers. You can also contact me on my talk page on meta if you would like. I'm working as a bridge between Wikimedia Foundation Engineering and Product Development, Wikimedia Stewards, and you to assure that SUL finalisation goes as smoothly as possible; this is a community-driven process and I encourage you to work with the Stewards for our communities.

Thank you for your time. -- Keegan (WMF) talk 18:24, 25 August 2014 (UTC)

--This message was sent using MassMessage. Was there an error? Report it!

xml dumps

Hi Daniel,

I saw that you had put in the warning for Wikidata:Database_download regarding xml dumps. Could you clarify what the issue is with the json provided there? As far as I can tell the xml dumps are the only ones that include all of the revisions rather than just the current state, is this correct?. I'm working on an analysis involving attributed each property to a user and it looks like diffs are going to be required. Does the api have the same problems as the xml dumps? Another Article (talk) 00:24, 21 August 2016 (UTC)

The problem with the JSON in the XML dumps is that it stays the same for old revisions when we change the JSON representation. The JSON is stored to the database using the representation that is valid at that point in time, and will not be changed, since revision data is immutable. So the XML dumps will contain various flavors of JSON from different versions of Wikibase. You can try to parse all of them, but it will get more and more messy over time; but that's what we do, since we need to be able to read old revisions forever.

If you use the generic MediaWiki API to retrieve old revision JSON, this will have the same problem as the XML dump. Raw revision data should really be treated as an opaque blob. Wikibase currently does not provide any API module for retrieving the JSON data of an old revision.

The only interface we currently have to access the canonical JSON of old revisions is Special:EntityData. You can use the revision=12345 parameter, e.g. https://www.wikidata.org/wiki/Special:EntityData/Q42.json?revision=32100 -- Daniel Kinzler (WMDE) (talk) 14:19, 23 August 2016 (UTC)

Do you have a json schema defined somewhere for each of the JSON representations? If I find some documentation for the schema I would be interested in writing a utility to convert between versions. It sounds like you already have something doing basically the same thing, is that code available anywhere to review? Thanks! Another Article (talk) 19:13, 24 August 2016 (UTC)

Request opinion about times

Since you edited mw:Wikibase/DataModel/JSON#time last year, Jura and I would like to ask a question which arose at Help talk:Dates#Days are in Universal Time, whether dates are intended to be local time or Universal Time (UT).

The timezone field is stated to be "unused" but it is implied that time zones together with times more precise than days could be supported in the future. It is also stated that timezone must be set to 0, and there is no mechanism to indicate the time is local. or to state the timezone is unknown, absent, unspecified, or any non-numerical value.

Also, the strings used to represent the time always end in "Z" which indicate (UT). It seems to me that at a minimum, indicate an original intention to treat these values as UT, and that historical intention has never been clearly repudiated. Looking at the sister document mw:Wikibase/Indexing/RDF Dump Format#Time, with the exception of dates in the database that are Julian and can't be converted to Gregorian, it states "The xsd:dateTime dates follow XSD 1.1 standard" which in turn states that the timezone may be absent, and that "Z" is a valid way to designate UT. The RDF emitted by Wikidata does include a "Z".

On the other hand, examples can be found of editors having simply copied the date as stated in a reliable source, without converting it to UT, and in the examples cited, the value is incorrect unless dateTimes are interpreted as local time. For example, the date of the end of the 2016 World Series (Q24906838) was 2 November 2016 US Eastern daylight time but 3 November 2016 UT. The 1945 Mikawa earthquake (Q4565560) occurred 13 January 1945 Japan Standard Time but 12 January 1945 UT.

The dates for many events, such as birth and death dates, were taken from sources which only give the date of the event in local time. Insufficient information exists to state the UT date, but it's essentially unheard of for editors to acknowledge this lack of precision by giving a precision of month and qualifiers of earliest date (P1319) and latest date (P1326). From this pattern, it's reasonable to conclude dateTime vaules are de facto local time. This status quo creates the situation that if time zones are ever supported, it will be necessary to provide a way to designate a date as local time, and to have a bot run through the database and change all the existing dateTimes to local time, to reflect the de facto usage. Jc3s5h (talk) 09:51, 3 July 2017 (UTC)