Well that took a little bit longer than I expected, but I've finally
finished indexing all of
Wikidata.org in Cirrus/Elasticsearch. It's currently enabled as the
secondary index, so
you can test it the usual way with srbackend parameters.
If things look good and people are satisfied with the results we can look
at making it
a primary index in the near future.
-Chad
Hi guys,
the ApiWikibase class currently mainly supports the editing of single
entities or getting claims etc, but still only for one single entity.
Api modules like GetEntities do not really fit into this class. Also,
there will be lots of Query Api modules in the future (see
https://bugzilla.wikimedia.org/show_bug.cgi?id=55967) who need their own
Api base class.
Thus I propose to rename the current ApiWikibase class to something like
ApiWikibaseSingle (I know the name is horrible but it shows what I mean)
and create another class called ApiWikibaseQuery or sth like that for
the query modules. Finally there could be a base class called
ApiWikibase again that provides general functions like getVersion() or
getHelpUrls().
Best regards,
Bene*
We have deployed new code to Wikidata. This includes various bug fixes and
some new features.
Changes of note include:
* Item ID is displayed next to the item label (see paper cut [1])
* Improved appearance of Wikimedia Commons site link section
In the API:
* EditEntity module allows editing / adding claims and creating entities
with claims.
* API has a new merge items module.
* Precision for time values is now validated. The API no longer accepts
time values more precise than a day, as such values are handled
inconsistently in the UI. (see bug 54939 [2])
* Coordinate values with null precision are no longer accepted by the API
for new claims.
In the clients (Wikivoyage/Commons now, Wikipedia on Thursday):
* The Wikidata flag 'D' on watchlist and recentchanges is styled.
[1]
https://www.wikidata.org/wiki/Wikidata:Paper_cuts#The_Q_number_is_nowhere_w…
[2] http://bugzilla.wikimedia.org/54939
Cheers,
Katie
--
Katie Filbert
Wikidata Developer
Wikimedia Germany e.V. | NEW: Obentrautstr. 72 | 10963 Berlin
Phone (030) 219 158 26-0
http://wikimedia.de
Wikimedia Germany - Society for the Promotion of free knowledge eV Entered
in the register of Amtsgericht Berlin-Charlottenburg under the number 23
855 as recognized as charitable by the Inland Revenue for corporations I
Berlin, tax number 27/681/51985.
Hey Tpt,
Hi! I'm working on a new version of wikibase-api-php based on the
> WikibaseDataModel component (the idea is to let the bots based on
> wikibase-api-php edit the Entity object and, when it's done, push back the
> changes to wikidata with the wbeditentity api). But, in order to make the
> conversion between Entity object and API representation (in the two
> directions) I need the code that is in the \Wikibase\lib\Serializer
> namespace of
> the Wikibase extension. Do you think it's possible to move these classes
> into a stand alone component? They doesn't looks to have strong
> dependancies on the other parts of the Wikibase extension.
>
It would be nice to see some data access abstraction mechanism on top of
our web API. So great to hear you are working on that \o/
There have been some emails about the serialization code mentioned lately,
as it is causing a number of problems and is, as you noticed, not really
reusable in its current state. What I'd like to see happen is this code
being refactored and put into its own component. We now have a much better
idea of how to do this cleanly going on our experiences with the
serialization code for the Ask library. So while it is not extremely tricky
of a think to do, it does require quite some work. And for now, we are sort
of blocked on creating new components due to requirements of the WMF
deployment process. It might still be some time before that is resolved.
Quoting myself from an email that was send last month on the internal list:
The old serialization and deserialization code (both db and external)
in Lib\Serializers
> is causing a lot of problems. The remaining bad dependencies in DataModel
> are caused by it, and cannot be removed without design flaws in the
> serialization code being fixed. New code, such as the datatype id stuff
> described above, can also not be implemented properly without refactoring
> first. A lot of the code is static, it all violates SRP and does not do
> proper dependency injection. I suggest creating a new serialization and
> deserialization component for the objects defined by the DataModel. This
> component could be shipped together with DataModel itself (and reside in
> the same git repo). It would be build on top of the Serializationcomponent [2] and would thus work similar to the
> serialization and deserialization code in Ask and WikibaseQuery, which
> has no known issues. This new component would then be used by Wikibase Repo
> and Wikibase Client instead of the code in lib, which would be removed.
> Some code build on top of the new component might need to be added in lib,
> as we might already have, or later on need, (de)serailization functionality
> that does not fit in the new component, which would only be dependent on
> DataModel (and its dependencies).
>
> It has been clear to me for quite some time that this code is not ideal (I
> already send some mail about this in the context of WikibaseQuery). Only
> recently I realized that fixing this essentially blocks removal of the last
> really bad dependencies in DataModel. Since we are running into situations
> where we need to choose between increasing the mess or fixing it, I think
> it is high time we do the later.
>
[2] https://github.com/wikimedia/mediawiki-extensions-Serialization
>
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
Hey,
Today I spotted some new code on gerrit breaking basic dependency rules,
making it clear that at least in Wikibase.git, the number if such
violations is not going down. It might in fact be increasing. Hence I'll
outline the basics here, in the hope people stop introducing these
violations.
* Wikibase Repo depends on WikibaseLib
* Wikibase Client depends on WikibaseLib
* Client and Repo do not depend on each other
>From this follows:
* Using Repo code in Lib is not allowed
* Using Client code in Lib is not allowed
* Using Client code in Repo is not allowed
* Using Repo code in Client is not allowed
There is no good reason to violate these points. "But", you might say,
"there are valid use cases for doing so". And yeah, if you want to follow
the Big Ball of Mud design pattern, you'd be right. If you run into a case
where at first glance it looks like you need to violate one of these rules,
consider that
* your design is very likely flawed in some way - violating these rules is
a strong design smell
* the flaw might well be solved by applying inversion of control
Rethinking your design might take some effort and time, esp if you already
committed to it by writing a pile of code. Laziness is however not an
excuse for creating design problems and ignoring things such as the acyclic
dependencies principle. To minimize the amount of work everyone needs to
do, including yourself, try to hold these basic rules into account when
designing your code. They are not complicated, and the benefit well
outweighs the little effort.
I expect people to adhere to these rules when submitting code, and when
reviewing. If new violations keep being introduced, we'll have to look at
enforcing these things automatically. I do hope we can muster the little
discipline to avoid the need for this.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
Hey,
just created a wmf-like deployment schedule for Wikidata [1] making the
"hardcoded" board in the office obsolete.
We should link to a page with a proper changelog, list of potential
breaking changes, new features, etc.. for each deployment. I've linked it
to aude's "deployment highlights" page for now until someone comes up with
a better idea.
cheers, tobi
[1] https://meta.wikimedia.org/wiki/Wikidata/Deployment
--
Tobi Gritschacher
Software Developer - Wikidata - http://www.wikidata.org
Imagine a world, in which every single human being can freely
share in the sum of all knowledge. That‘s our commitment.
Wikimedia Deutschland e.V. | Obentrautstraße 72 | 10963 Berlin
Phone +49 (0)30 219 158 260
http://wikimedia.de <http://www.wikimedia.de/>
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Hello!
The EasyRdf submodule was updated to a new version to avoid
a bug with the serialization of integers in turtle format.
https://gerrit.wikimedia.org/r/#/c/86858/ has been merged
This will require you to run 'git submodule update' after
pulling master otherwise RDF unit tests will fail on master.
Adam
(crossposting from http://blog.wikimedia.de/?p=17250)
In early 2010 I met Denny and Markus for the first time in a small
room at the Karlsruhe Institute of Technology to talk about Semantic
MediaWiki, its development and its community. I was intrigued by the
idea they'd been pushing for since 2005 - bringing structured data to
Wikipedia. So when the time came to assemble the team for the
development of Wikidata and Denny approached me to do community
communications for it there was no way I could have said no. The
project sounded amazing and the timing was perfect since I was about
to finish my studies of computer science. In the one and a half years
since then we have achieved something amazing. We've built a great
technical base for Wikidata and much more importantly we've built an
amazing community around it. We've built the foundation for something
extraordinary. On a personal level I could never have dreamed where
this one meeting in a small room in Karlsruhe has taken me now.
>From now on I will be taking over product ownership of Wikidata as its
product manager.
Up until today we've built the foundation for something extraordinary.
But at the same time there are still a lot of things that need to be
worked on by all of us together. The areas that we need to focus on
now are:
* Building trust in our data. The project is still young and the
Wikipedia editors and others are still wary of using data from
Wikidata on a large scale. We need to build tools and processes to
make our data more trustworthy.
* Improving the user experience around Wikidata. Building Wikidata to
the point where it is today was a tremendous technical task that we
achieved in a rather short time. This though meant that in places the
user experience has not gotten as much attention. We need to make the
experience of using Wikidata smoother.
* Making Wikidata easier to understand. Wikidata is a very geeky and
technical project. However to be truly successful it will need to be
easy to get the ideas behind it.
These are crucial for Wikidata to have the impact we all want it to
have. And we will all need to work on those - both in the development
team and in the rest of the Wikidata community.
Let's make Wikidata a joy to use and get it used in places and ways we
can't even imagine yet.
Cheers
Lydia
--
Lydia Pintscher - http://about.me/lydia.pintscher
Product Manager for Wikidata
Wikimedia Deutschland e.V.
Obentrautstr. 72
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/681/51985.
Dear all,
FYI: a project proposal for creating a software toolkit to work with
Wikidata data in external tools [1]. Sent to wikidata-l, but maybe it's
also interesting for those working with semantic data here.
Feedback and support is welcome. Having email replies go to wikidata-l
would be great, but don't let this hold you back if you're not on there.
You can also post to the bottom of the wiki page [1].
Cheers,
Markus
[1] https://meta.wikimedia.org/wiki/Grants:IEG/Wikidata_Toolkit
-------- Original Message --------
Subject: [Wikidata-l] Wikidata Toolkit: call for feedback/support
Date: Sun, 29 Sep 2013 13:11:11 +0100
From: Markus Krötzsch <markus(a)semantic-mediawiki.org>
Reply-To: Discussion list for the Wikidata project.
<wikidata-l(a)lists.wikimedia.org>
To: Discussion list for the Wikidata project.
<wikidata-l(a)lists.wikimedia.org>
Dear Wikidatanions (*),
I have just drafted a little proposal for creating more tools for
external people to work with Wikidata, especially to build services on
top of its data [1]. Your feedback and support is needed.
Idea: Currently, this is quite hard for people, since we only have WDA
for reading/analysing dumps [2] and Wikidata Query as a single web
service to ask queries [3]. We should have more support for programmers
who want to load, query, analyse, and otherwise use the data. The
proposal is to start such a toolkit to enable more work with the data.
The plan is to kickstart this project with a small team using
Wikimedia's Individual Engagement program. For this we will need your
support -- feel free to add your voice to the wiki page [1]. Of course,
comments of all sorts are also great -- this email thread will be linked
from the page. If you would like to be involved with the project, that's
great too; let me know and I can add you to the proposal.
The proposal will already be submitted tomorrow, but support should also
be possible after that, I hope.
Cheers,
Markus
(*) Do we have a demonym yet? Wikipedian sounds natural, Wikidatan less
so. Maybe this should be another thread ... ;-)
[1] https://meta.wikimedia.org/wiki/Grants:IEG/Wikidata_Toolkit
[2] http://github.com/mkroetzsch/wda
[3] http://208.80.153.172/wdq/
--
Markus Kroetzsch, Departmental Lecturer
Department of Computer Science, University of Oxford
Room 306, Parks Road, OX1 3QD Oxford, United Kingdom
+44 (0)1865 283529 http://korrekt.org/
_______________________________________________
Wikidata-l mailing list
Wikidata-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Hi all!
As discussed at the MediaWiki Architecture session at Wikimania, I have created
an RFC for the TitleValue class, which could be used to replace the heavy-weight
Title class in many places. The idea is to show case the advantages (and
difficulties) of using true "value objects" as opposed to "active records". The
idea being that hair should not know how to cut itself.
You can find the proposal here:
<https://www.mediawiki.org/wiki/Requests_for_comment/TitleValue>
Any feedback would be greatly appreciated.
-- daniel
PS: I have included the some parts of the proposal below, to give a quick
impression.
------------------------------------------------------------------------------
== Motivation ==
The old Title class is huge and has many dependencies. It relies on global state
for things like namespace resolution and permission checks. It requires a
database connection for caching.
This makes it hard to use Title objects in a different context, such as unit
tests. Which in turn makes it quite difficult to write any clean unit tests (not
using any global state) for MediaWiki since Title objects are required as
parameters by many classes.
In a more fundamental sense, the fact that Title has so many dependencies, and
everything that uses a Title object inherits all of these dependencies, means
that the MediaWiki codebase as a whole has highly "tangled" dependencies, and it
is very hard to use individual classes separately.
Instead of trying to refactor and redefine the Title class, this proposal
suggest to introduce an alternative class that can be used instead of Title
object to represent the title of a wiki page. The implementation of the old
Title class should be changed to rely on the new code where possible, but its
interface and behavior should not change.
== Architecture ==
The proposed architecture consists of three parts, initially:
# The TitleValue class itself. As a value object, this has no knowledge about
namespaces, permissions, etc. It does not support normalization either, since
that would require knowledge about the local configuration.
# A TitleParser service that has configuration knowledge about namespaces and
normalization rules. Any class that needs to turn a string into a TitleValue
should require a TitleParser service as a constructor argument (dependency
injection). Should that not be possible, a TitleParser can be obtained from a
global registry.
# A TitleFormatter service that has configuration knowledge about namespaces and
normalization rules. Any class that needs to turn a TitleValue into a string
should require a TitleFormatter service as a constructor argument (dependency
injection). Should that not be possible, a TitleFormatter can be obtained from a
global registry.