Hey,
While working on the serialization and deserialization code for Ask (which
is now finally done - yay!), I figured we'd have use for the same
interfaces, exceptions and basic utilities almost everywhere we do this
kind of work. After bouncing of the idea to put this into its own component
of some people, I went ahead with this. The new component is named
Serialization (we failed to come up with a better name) and is now in a WMF
git repo.
You can browse the code at
https://github.com/wikimedia/mediawiki-extensions-Serialization
For now, the only direct dependency on this component is the Ask library.
It'll need to be included for deployment as soon as we deploy the
WikibaseQuery extension. Or as soon as we decide to load Ask for some other
reason.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
Hi guys,
I've modified /etc/ssh/sshd_config repeatedly on this wikidata-suggester
labs instance, and once I log out and log in after sometime it gets reset
to what it originally was. What sorcery is this? :P Something to do with
Puppet?
The file contains these lines:
#AuthorizedKeysFile %h/.ssh/authorized_keys
AuthorizedKeysFile /etc/ssh/userkeys/%u/.ssh/authorized_keys
/public/keys/%u/.ssh/authorized_keys
But I need the commented line. I usually uncomment it and comment out the
line below it, restart sshd, run my hadoop jobs, log out; the next time I
log in, I find the file reset.
Cheers,
Nilesh
--
A quest eternal, a life so small! So don't just play the guitar, build one.
You can also email me at contact(a)nileshc.com or visit my
website<http://www.nileshc.com/>
Heya folks :)
So we're finally starting to get real with this sister projects thing.
We'll be starting with Wikivoyage since this is comparatively similar
to Wikipedia. We'll take it easy at the beginning and just go for the
language links between the different language editions of Wikivoyage.
On July 18th we will change test.wikidata.org to be able to store
links to Wikivoyage in addition to Wikipedia. You can test it there
then and make sure there are no huge issues we have not noticed yet.
On July 22 we will enable this on wikidata.org and the Wikivoyages.
Some things to keep in mind:
* This is only for links between Wikivoyages for now. More will follow later.
* Access to the other data like timezones, airport codes and so on
will not be enabled yet. That will follow later as well.
* There will be no automatic links to/from Wikipedia for now.
Some specific things about the language links:
* It'll no longer be needed to keep them in the wikitext like it is currently.
* It'll still be possible to do so however but this will overwrite the
links coming from Wikidata.
* With the magicword noexternallanglinks links from Wikidata can be
turned off on an article either for all languages or only specific
ones.
A page on Wikidata has been created where you can find someone to help
you in case of issues
(http://www.wikidata.org/wiki/Wikidata:Wikivoyage_migration) and as
usual I am available to answer any questions you might have.
Cheers
Lydia
--
Lydia Pintscher - http://about.me/lydia.pintscher
Community Communications for Technical Projects
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.
Sorry, I had a typo in the title of my last Email. It should be Wikivoyage
obviously, not Wikileaks or Wikisomethingelse.
Cheers,
Denny
2013/6/28 Denny Vrandečić <denny.vrandecic(a)wikimedia.de>
> Hey all,
>
> as discussed yesterday in the call, here is our current plan for deploying
> interwikilinks to Wikivoyage. If there are no complaints from your side by
> Tuesday, we will share this plan with the Wikivoyage communities and the
> Wikidata community on Wednesday.
>
>
> Wed, July 17th: Branching Wikibase 1.22-wmf12
>
> Thu, July 18th: Deploying wmf12 to the test systems and setting up
> configurations for Wikivoyage on test. This means, the Test Wikidata can
> accept links to Wikivoyage sites.
>
> Mon, July 22nd: Deploying wmf12 to wikidata.org and setting the
> configuration to accept Wikivoyage links as well.
>
> Thu, July, 25th: Deploying wmf12 client to all Wikivoyage.org language
> editions. From this moment on, Wikivoyage can access interwiki links from
> Wikidata, and does not need to have them locally anymore.
>
>
>
> Notes:
>
> * Wikivoyage will only get access to the interwikis for now, not to other
> data in Wikidata. This is planned for later, but we just want to go step by
> step (i.e. only "phase 1")
>
> * Wikipedia will not automatically and suddenly display links to
> Wikivoyage. The behavior on Wikipedia actually remains completely unchanged
> by this deployment.
>
> * Wikivoyage will not automatically get links to Wikipedia and display
> them (currently called "Related sites"). This is also left for later.
>
> * Further sister projects are planned for later, depending how smoothly
> this deployment goes.
>
> * There is no need for an additional item for e.g. New York for
> Wikivoyage, but rather the links to Wikivoyage can be entered in the same
> item that also holds the links to Wikipedia.
>
> Cheers,
> Denny
>
> P.S.: Ken, you might consider joining the Wikidata tech list. This is
> where we send the agenda for the Thursday calls around.
>
>
>
> --
> Project director Wikidata
> Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
> Tel. +49-30-219 158 26-0 | http://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.
>
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://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.
Hey there!
I am writing my master thesis, an identification key for trees. A
preview is currently here:
http://ec2-54-234-76-44.compute-1.amazonaws.com/
(address may/will change).
The key (filter.php) can already be edited (editor.php), but without
history etc. Wikibase suits the requirements perfectly – you wrote it
just in time. Characters of trees are language independant,
descriptions are not; exactly what Wikibase does.
There is one point I need help with: I need a list of all
Questions/Characters/Taxa, i.e. pretty much a table dump, for the
editor (processing is all done with JavaScript). What way would you
suggest? \Wikibase\Store only returns Entities for known IDs, and I
have found no other function so far.
To distinguish between the different kinds of object (question,
character, etc.) I plan to use instance-of properties and make the IDs
of the used properties (instance-of, parent, …) and items (question,
character, taxon, …) configurable in the extension.
Greetings from Switzerland,
Simon
Hey all,
as discussed yesterday in the call, here is our current plan for deploying
interwikilinks to Wikivoyage. If there are no complaints from your side by
Tuesday, we will share this plan with the Wikivoyage communities and the
Wikidata community on Wednesday.
Wed, July 17th: Branching Wikibase 1.22-wmf12
Thu, July 18th: Deploying wmf12 to the test systems and setting up
configurations for Wikivoyage on test. This means, the Test Wikidata can
accept links to Wikivoyage sites.
Mon, July 22nd: Deploying wmf12 to wikidata.org and setting the
configuration to accept Wikivoyage links as well.
Thu, July, 25th: Deploying wmf12 client to all Wikivoyage.org language
editions. From this moment on, Wikivoyage can access interwiki links from
Wikidata, and does not need to have them locally anymore.
Notes:
* Wikivoyage will only get access to the interwikis for now, not to other
data in Wikidata. This is planned for later, but we just want to go step by
step (i.e. only "phase 1")
* Wikipedia will not automatically and suddenly display links to
Wikivoyage. The behavior on Wikipedia actually remains completely unchanged
by this deployment.
* Wikivoyage will not automatically get links to Wikipedia and display them
(currently called "Related sites"). This is also left for later.
* Further sister projects are planned for later, depending how smoothly
this deployment goes.
* There is no need for an additional item for e.g. New York for Wikivoyage,
but rather the links to Wikivoyage can be entered in the same item that
also holds the links to Wikipedia.
Cheers,
Denny
P.S.: Ken, you might consider joining the Wikidata tech list. This is where
we send the agenda for the Thursday calls around.
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://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.
Hi,
I am Chinmay Naik, a GSoc intern working on a "Gene Bot" for Crowdsourcing
Biology. We are considering about a search interface which retrieves
wikidata items based on properties. Something similar to this (
http://www.wikidata.org/wiki/Wikidata:Tools#WikiData_query). Any
suggestions/pointers regarding this would be of great help.
Thanks,
Chinmay
Hi Tobi, hi Katie.
I have just merged Marius' "Client to Repo move change propagation" patch:
https://gerrit.wikimedia.org/r/#/c/65648/
This will automatically change sitelinks on the repo when a (connected) page on
the client is moved.
This required CentralAuth to work.
It would be good to have selenium tests for this, and to have our test systems
configured for checking this manually, too. I have filed a bug for this:
https://bugzilla.wikimedia.org/show_bug.cgi?id=50244
Thanks!
Daniel
I'm currently working on validation, and would like some input on the following
issue:
Data we already have in the database may become "invalid" by some definition.
This may happen because a property is deleted, the type of a property changes,
or rules for validation become stricter, etc.
It would be bad if an invalid Snak somewhere in an entity would cause all
processing of that claim or entity to fail - which would be the case if we just
triggered an exception when we encountered such a snak. Just skipping over such
Snaks would bean silently removing them with the next edit - also not a great
option.
We really want to be able to show the snak as invalid in the UI, and allow users
to replace it with something valid or remove it explicitly. So I came up with
the notion of a PropertyBadValueSnak to represent invalid snaks. Relevant
patches on gerrit:
https://gerrit.wikimedia.org/r/#/c/68952/https://gerrit.wikimedia.org/r/#/c/68002/
(if you can't see these, it'S because they are tagged as "draft" and gerrit
makes drafts visible only to invited reviewers... let me know and I'll add you).
So, to you think this is a good approach? Is the Snak level the right place for
handling this case?
-- daniel