Wikidata-tech

wikidata-tech@lists.wikimedia.org

1 participants
622 discussions

Breaking change: improving the schema of wb_terms table
by Léa Lacroix 08 Jun '17

08 Jun '17

Hello, This is an important information regarding our database, for people running tools and scripts. *The change* In the wb_terms table, a new column term_full_entity_id containing strings with the full ID including the letter (ie. “Q42”) will be created, and will be used instead of the current column term_entity_id that only stores the numeric part of the ID (ie. “42”). This change is made, among other things, to support the new entity types to come, and then to store terms of entities that have non-numeric IDs, for example Forms (“L42-F1”). *Implications* - This change only affects tools that directly access the database. Other tools, for example those getting data through the API, pywikibot, gadgets, etc. will not be affected and will work as before with no action required from the maintainers. - in order to adapt tools to the new database structure, database queries using wb_terms should be changed so that they use term_full_entity_id column instead of term_entity_id. This might potentially simplify queries. For example, instead of having a condition WHERE term_entity_type='item' AND term_entity_id=42, one could now do: WHERE term_full_entity_id='Q42'. - term_entity_type is not affected by this change, and will still be available as before. *The process* Starting now, we will work through several steps to achieve this change. Note that the dates indicated below may not be exact. We will announce each of the steps separately. Here is a rough timeline: - June 22th: the new column, term_full_entity_id, becomes visible on Labs. It will be fully populated in the testwikidatawiki database replica on Labs. Note that this column will remain incomplete in the wikidatawiki database until later! Tools that use the wb_terms table can test new code that uses the new term_full_entity_id column with the testwikidatawiki database, but must keep using the old code with the wikidatawiki database. - Some time later: testwikidatawiki should be fully populated, and become usable on the wikidatawiki database. Tools that use the wb_terms table can now switch to using new code that no longer uses the old term_entity_id column on all databases. - Eventually (not before July 6th): the old term_entity_id column is removed from the testwikidatawiki and wikidatawiki database replicas on labs. Any code that still uses the old term_entity_id will break. If you have any question or problem regarding this change, feel free to answer to this mail or write directly to me. -- Léa Lacroix Project Manager Community Communication for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207.

1 0

Wikidata Zurich: Workshop and Participating at HackZurich (14.09, 15.09-17.09)
by wikidata zurich 06 Jun '17

06 Jun '17

Hi everyone, In September 2017 (15.09-17.09), one of the largest hackathons in Europe will take place in Zurich, Switzerland. The event is called HackZurich <http://digitalfestival.ch/en/HACK/> and it is organized together with the Digital Festival 2017 <http://digitalfestival.ch/en>. It is a great opportunity to make open data enthusiasts and hackers in general aware of Wikidata, and we would also like to team up with other Wikidata developers to *participate at HackZurich*. One day before HackZurich, on Thu 14.09 we will be *organising a Wikidata workshop* at the University of Zurich, where we would like to offer information and training about Wikidata. All the information about both the Wikidata workshop and the participation at HackZurich can be found at the event's page: https://www.wikidata.org/wiki/Wikidata:Events/Wikidata_Zurich *Important*: the registration for HackZurich opens on Friday 09.06. The workshop also requires registration <https://docs.google.com/forms/d/e/1FAIpQLSd2srUW6LjdnkpmDUKz-SkE20kGxGImX8Z…> . If you would like to help out in the workshop or/and participate in the hackathon, please register in each of the events and let us know in the Talk page: https://www.wikidata.org/wiki/Wikidata_talk:Events/Wikidata_Zurich Thanks! Cristina Sarasua and Leon Kastler

1 0

RDF to wikibase
by Dennis Diefenbach 05 Jun '17

05 Jun '17

Hello everyone, first, thank you for providing Wikibase!!!! We have put up a local Wikibase service, and we are interesting to import in it RDF. We figured out that one option is using the wikibase APIs but we thought that maybe someone already had this problem. We found the following project https://github.com/rdfio/RDFIO <https://github.com/rdfio/RDFIO>, but if we got it right it does not fit. Any ideas, pointers? Thank you Dennis Diefenbach <http://laboratoirehubertcurien.fr/> Dennis DIEFENBACH Doctorand dennis.diefenbach(a)univ-st-etienne.fr <mailto:dennis.diefenbach@univ-st-etienne.fr> Laboratoire Hubert Curien Campus Manufacture 18 RUE Pr Benoît Lauras 42000 SAINT-ETIENNE 04 77 91 57 80 http://laboratoirehubertcurien.fr <http://laboratoirehubertcurien.fr/> <http://www.univ-st-etienne.fr/> <http://www.facebook.com/Universite.Jean.Monnet.Saint.Etienne> <https://twitter.com/Univ_St_Etienne> <https://www.youtube.com/user/UniJeanMonnetUJM> <https://www.linkedin.com/edu/universit%C3%A9-jean-monnet-saint-etienne-12533> <http://www.viadeo.com/fr/company/universite-jean-monnet> <http://www.universite-lyon.fr/>

1 0

Breaking change: "wb_entity_per_page" table will not be updated and replicated on ToolLabs anymore
by Lydia Pintscher 01 Jun '17

01 Jun '17

Hi everyone, This is an important message to all the people running external tools. About 2 years ago we said we want to get rid of the "wb_entity_per_page" table. This is still the case and is becoming more pressing now with the introduction of support for lexicographical data. On July 12th, we are going to stop updating the "wb_entity_per_page" table from the Wikibase database and stop its replication on ToolLabs. At a later point we will remove it completely. "wb_entity_per_page" was a secondary database table, mapping Wikibase entity IDs (e.g. "Q42") to MediaWiki page IDs (e.g. 138, which can be seen at https://www.wikidata.org/wiki/Q42?action=info). "wb_entity_per_page" stored entity IDs as numbers, while page titles are always full entity IDs. This mapping existed because Wikibase was designed with the possibility to have entity pages where the ID does not match the title. This idea was never used, and finally removed in 2015 (documented in https://phabricator.wikimedia.org/T95685). We decided to get rid of the table because it contains outdated information that could mislead users, it costs resources and could conflict in the future with our new entity types for lexicographical data. Please check if you are maintaining any code that accesses the "wb_entity_per_page" table, and replace it with lookups to MediaWiki's "page" and "redirect" tables. We will drop the replica of the table on ToolLabs for test.wikidata.org on June 28th. We will do the same for wikidata.org on July 12th. If you have any question or issue, feel free to add a comment on the ticket (http://phabricator.wikimedia.org/T95685) or to ping me. Thanks for your understanding Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207.

3 5

Merged Items as Property Targets in Statements
by Miguel Paraz 21 May '17

21 May '17

Hi! I see that when I use the Java API to add a Statement with a Property pointing to an Item, but the Item has been merged: org.wikidata.wdtk.wikibaseapi.apierrors.MediaWikiApiErrorException: [modification-failed] [[Item:Q1040|Q1040]] not found at org.wikidata.wdtk.wikibaseapi.apierrors.MediaWikiApiErrorHandler.throwMediaWikiApiErrorException(MediaWikiAp iErrorHandler.java:62) Is there a way to put in Items such that Wikibase would point them to the merge target? Or, do I need to use the API to find out the merge target so I could use that instead? Thanks! Cheers Miguel

5 6

Timestamp of change in user rights
by Cristina Sarasua 05 May '17

05 May '17

Hi, Is there a way to programmatically read the timestamp that indicates when Wikidata editors changed their user rights? I would like to query the edit history dump or the API to know when someone becomes a bureaucrat or an administrator. Thanks in advance, Cristina -- Cristina Sarasua Institute for Web Science and Technologies (WeST) Universität Koblenz-Landau Universitätsstraße 1 56070 Koblenz Germany e-mail: csarasua(a)uni-koblenz.de phone: +49 261 287 2772 fax: +49 261 287 100 2772 web site: http://west.uni-koblenz.de

2 2

Significant change: new data type for tabular data files
by Léa Lacroix 02 May '17

02 May '17

Hello all, We’ve been working on a new data type that allows you to link to the *tabular data files <https://www.mediawiki.org/wiki/Help:Tabular_Data>* that are now stored on Commons. This data type will be deployed on Wikidata on *May 15th* . The property creators will be able to create properties with this tabular data type by selecting “tabular data” in the data type list. When the property is created, you can use it in statements, and when filling the value, if you start typing a string, you can choose the name of a file in the list of what exists on Commons. Before the deployment, you can test it on http://test.wikidata.org (example <https://test.wikidata.org/wiki/Q59992>). One thing to note: We currently do not export statements that use this datatype to RDF. They can therefore not be queried in the Wikidata Query Service. The reason is that we are still waiting for tabular data files to get stable URIs. This is handled in this ticket <https://phabricator.wikimedia.org/T161527>. If you have any question, feel free to ask! -- Léa Lacroix Project Manager Community Communication for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207.

2 1

Script and API module for constraint checks
by Léa Lacroix 27 Apr '17

27 Apr '17

Hello all, In the past few months, the development team has mentored a student, Olga, to help us developing a user script <https://www.wikidata.org/wiki/User:Jonas_Kress_%28WMDE%29/check_constraints…> that displays the constraints on the item pages. To use the script, add the following line to your user/common.js: mw.loader.load( '//www.wikidata.org/w/index.php?title=User:Jonas_Kress_(WMDE)/check_constraints.js&action=raw&ctype=text/javascript' ); You will see an icon [image: Icon used on the user script for constraint reports on Wikidata] <https://commons.wikimedia.org/wiki/File:Constraint_icon.png> next to violations. When you click it you will see the full report. [image: Screenshot of the user script checking constraints on Wikidata] <https://commons.wikimedia.org/wiki/File:Screenshot_constraint_check_Wikidat…> This script is based on a new API module for constraint checks <https://www.wikidata.org/wiki/Special:ApiSandbox#action.3Dwbcheckconstraint…> that one can use to check constraints on items and statements. At the moment, the constraint checks are only derived from the property discussion page constraint templates, not directly from statements. They are then stored in a database table. We are running a script to update this table every now and then or when you ask for it. Also note that some constraint checks are disabled (for example the format check). In the future we will support adding and updating constraints on property statements and we will implement support for some constraints that are currently still missing. If you try it, feel free to give us feedback! You can also add comments or subtasks on Phabricator (see the ticket for the API module <https://phabricator.wikimedia.org/T102757> and the user script <https://phabricator.wikimedia.org/T97018>). If there is no major disagreement, we would like to turn this script into a gadget in the next days. Thanks go to Olga and all the developers that helped her providing this new feature :) See also: - API Documentation <https://www.mediawiki.org/wiki/Wikibase/API#wbcheckconstraints> - Self-documentation for the module <https://www.wikidata.org/w/api.php?action=help&modules=wbcheckconstraints> Cheers, -- Léa Lacroix Project Manager Community Communication for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/029/42207.

4 3

rdfs:label referring to non-existent column causes Blazegraph high CPU/RAM and then MemoryManagerOutOfMemory
by Miguel Paraz 24 Apr '17

24 Apr '17

Hi, I'm referring to a query like this, based on the Wikidata cats example: SELECT ?item WHERE { ?item wdt:P31 wd:Q146 . ?crash rdfs:label ?_crashLabel } on my local Blazegraph, I can see that it uses up all the CPU cores and goes up in RAM, and eventually kills the query with: Caused by: com.bigdata.rwstore.sector.MemoryManagerOutOfMemory at com.bigdata.rwstore.sector.MemoryManager.getSectorFromFreeList(MemoryManager.java:646) Could Blazegraph prevent this query from even starting? Thanks! Cheers Miguel

2 1

Diacritic insensitive search not working?
by Thad Guidry 18 Apr '17

18 Apr '17

I am not able to successfully get results on topics that have diacritics in their label while logged in and searching Wikidata. Searching for "Marc Marquez" this morning did not show any results. I began to create an entry for this motorcycle road racer and later discovered that he already had an entry. I noticed that the "Also known as" for English only had a diacritic label "Marc Márquez i Alentà ". I then added another "Also known as" Marc Marquez and this resolved the problem of finding the correct original topic. I merged my erroneous new topic into the original https://www.wikidata.org/wiki/Q40615 Is there an effort already in progress to fix diacritic insensitive search or investigate why it might not be working for logged in English users ? I only found this older Phabricator issue for Autocomplete during data entry, and not main search: https://phabricator.wikimedia.org/T49114 -Thad +ThadGuidry <https://www.google.com/+ThadGuidry>

2 3

← Newer
1
...
24
25
26
27
28
29
30
...
63
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Wikidata-tech