Hello,
The Wikidata development team at Wikimedia Deutschland is planning a brief
survey of the Wikidata community to understand the diverse ways people
contribute to the project and identify patterns in user contributions.
To yield representative results, we want to deploy the survey to a broad
range of users via the CentralNotice
<https://meta.wikimedia.org/wiki/CentralNotice>. We have put up a request
for a CentralNotice banner
<https://meta.wikimedia.org/wiki/CentralNotice/Request/Wikidata_Community_Su…>;
the request is open for your feedback and comments.
Please take a look and let us know if you have any questions.
Cheers,
--
Mohammed S. Abdulai
*Community Communications Manager, Wikidata*
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0) 30 577 116 2466
https://wikimedia.de
Grab a spot in my calendar for a chat: cal.com/masssly.
A lot is happening around Wikidata - Keep up to date!
<https://www.wikidata.org/wiki/Wikidata:Status_updates> Current news and
exciting stories about Wikimedia, Wikipedia and Free Knowledge in our
newsletter (in German): Subscribe now <https://www.wikimedia.de/newsletter/>
.
Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de
Wikimedia Deutschland — Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Charlottenburg, VR 23855 B.
Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin,
Steuernummer 27/029/42207. Geschäftsführende Vorstände: Franziska Heine,
Dr. Christian Humborg
Hi everyone,
This is a breaking change announcement relevant for some Wikibase API users.
What is Changing?
On 2 July 2024, we will enable the EntitySchema data type on Wikidata, and
we expect the community to create the first properties with that data type
and start using them in statements shortly afterwards. This means that
there will be values with the data value type wikibase-entityid containing
an EntitySchema ID (with "entity-type": "entity-schema" in the JSON value).
However, EntitySchema is not yet a full-featured Wikibase entity type; it
is our intention to eventually make it work like other entity types (Item,
Property, etc.), but at the moment, using EntitySchema in e.g. the
wbgetentities API or Special:EntityData does not work.
Who is Affected?
Code which assumes that IDs found in wikibase-entityid data values can be
used with other Wikibase entity APIs may need adjusting.
Other Wikibases instances besides Wikidata are not affected unless they
also use the EntitySchema extension and set $wgEntitySchemaEnableDatatype =
true.
What You Need to Do
If your code works with statements of arbitrary data types, and looks up
entities referenced in values with the data value type wikibase-entityid,
you probably want to check that the entity-type is not entity-schema before
proceeding. (Note that, if your goal is to display the value, you can
instead use the wbformatvalue API for any data type.)
If you use the wbformatvalue API, you should make sure that you also
specify the datatype or property parameter (depending on which information
you have available; note that specifying both parameters at once is an
error). Without this information, not all values can be formatted
correctly; in particular, trying to format an EntitySchema value without
specifying the datatype or property will result in an error (“An illegal
set of parameters have been used”). (Specifying the datatype or property
parameter for wbformatvalue has always been advisable, and necessary for
some other data value types, but this is the first time it becomes relevant
for wikibase-entityid data values.)
As previously announced
<https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/th…>,
the new data type is already enabled on Test Wikidata, so you can try out
the behaviour there. (An example item on Test Wikidata with a statement
linking to an EntitySchema is human <https://test.wikidata.org/wiki/Q497>.)
If you have any questions or concerns about this change, please don’t
hesitate to reach out to us in this ticket (T332157
<https://phabricator.wikimedia.org/T332157>).
Cheers,
Lydia
--
Lydia Pintscher - https://lydiapintscher.de - WD:Q18016466
<https://www.wikidata.org/wiki/Q18016466>
Portfolio Lead for Wikidata
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30-577 11 62-0
https://wikimedia.de
Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de
Wikimedia Deutschland — Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Charlottenburg, VR 23855 B.
Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin,
Steuernummer 27/029/42207. Geschäftsführende Vorstände: Franziska Heine,
Dr. Christian Humborg
Hello all!
The feedback period for our WDQS Graph Split proposal
<https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_graph_spli…>
has
come to an end. Many thanks to all people who sent comments, your
contribution is invaluable!
We’ve incorporated most comments and proposals into our final set of rules
for the graph split
<https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_graph_spli…>.
The main proposals (including some that were rejected) were:
- Duplicate properties in both graph (wd:P*) does not seem necessary and
won't be done
- The list of types of publications that identify what is a scholarly
article have been improved, see the final list of items here
<https://docs.google.com/spreadsheets/d/1eKX_2Z1rXj1s_zOapQvn_0uD6MVhc-qyqqx…>
- It was discussed whether sitelinks should inform the nature of the
split or not; this idea was not incorporated because it might make it
harder to understand what is where
- Discussions and investigations regarding items that define
multiple instance
of (P31) <https://www.wikidata.org/wiki/Property:P31> which might be
ambiguous, it appears that it might not affect a lot of items and that the
solution might be to disambiguate these instances by creating separate
entities (see the Clinical Trials section
<https://www.wikidata.org/wiki/Wikidata_talk:SPARQL_query_service/WDQS_graph…>
of
the Talk Page).
- Re-thinking how scholarly articles are modelled was raised, especially
by identifying the nature of the publication using a separate property
rather than using instance of (P31)
<https://www.wikidata.org/wiki/Property:P31>. This idea should probably
be explored and discussed by the wikicite community, since it does affect
the nature of the split but could be a nice criteria to take into
consideration in the future.
We are now working on implementing the appropriate tooling to manage this
split, including a new way of processing the Wikidata dumps for an initial
load, modification to the update pipeline to support the graph split, and
additional automation. We hope to have new SPARQL endpoints that are live
updated with the graph split by the end of June. This timeline is probably
slightly optimistic, we’ll let you know when those are ready.
Once the new SPARQL endpoints that are live updated with the graph split
are available, we will provide a 6 months transition period, during which
the current endpoint (query.wikidata.org/sparql) will keep serving the full
graph. Once that transition is over, query.wikidata.org will only serve the
main graph. Queries that need federation will need to be rewritten. You can
ask for help to rewrite queries
<https://www.wikidata.org/wiki/Wikidata:Request_a_query_rewrite>.
Thank you all for your help and support!
Guillaume
--
*Guillaume Lederrey* (he/him)
Engineering Manager
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello all!
The Search Platform Team usually holds an open meeting on the first
Wednesday of each month. Come talk to us about anything related to
Wikimedia search, Wikidata Query Service (WDQS), Wikimedia Commons Query
Service (WCQS), etc.!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, June 5, 2024
Time: 15:00-16:00 UTC / 08:00 PDT / 11:00 EDT / 17:00 CEST
Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours
Google Meet link: https://meet.google.com/vgj-bbeb-uyi
Join by phone: https://tel.meet/vgj-bbeb-uyi?pin=8118110806927
Have fun and see you soon!
Guillaume
--
*Guillaume Lederrey* (he/him)
Engineering Manager
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello all,
The next language community meeting is scheduled in a few weeks - May 31st
at 16:00 UTC. If you're interested, you can sign up on this wiki page: <
https://www.mediawiki.org/w/index.php?title=Wikimedia_Language_engineering/…
>.
This is a participant-driven meeting, where we share language-specific
updates related to various projects, collectively discuss technical issues
related to language wikis, and work together to find possible solutions.
For example, in the last meeting, the topics included the machine
translation service (MinT) and the languages and models it currently
supports, localization efforts from the Kiwix team, and technical
challenges with numerical sorting in files used on Bengali Wikisource.
Do you have any ideas for topics to share technical updates related to your
project? Any problems that you would like to bring for discussion during
the meeting? Do you need interpretation support from English to another
language? Please reach out to me at ssethi(a)wikimedia.org and add
agenda items to the document here: <
https://etherpad.wikimedia.org/p/language-community-meeting-may-2024>.
We look forward to your participation!
Cheers,
Jon, Mary, Oscar, Amir and Srishti
*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>