Dear users, developers and all people interested in semantic wikis,
We are happy to announce SMWCon Fall 2013 - the 8th Semantic MediaWiki
* Dates: October 28th to October 30th 2013 (Monday to Wednesday)
* Location: A&O Berlin Hauptbahnhof, Lehrter Str. 12, 10557 Berlin, Germany
* Conference wikipage: https://semantic-mediawiki.org/wiki/SMWCon_Fall_2013
* Participants: Everybody interested in semantic wikis, especially in
Semantic MediaWiki, e.g., users, developers, consultants, business
SMWCon Fall 2013 will be supported by the Open Semantic Data
Association e. V. . Our platinum sponsor will be WikiVote ltd,
Following the success of recent SMWCons, we will have one tutorial day
and two conference days.
Participating in the conference: To help us planning, you can already
informally register on the wikipage, although a firm registration will
later be needed.
Contributing to the conference: If you want to present your work in
the conference please go to the conference wikipage and add your talk
there. To create an attractive program for the conference, we will
later ask you to give further information about your proposals.
Tutorials and presentations will be video and audio recorded and will
be made available for others after the conference.
==Among others, we encourage contributions on the following topics==
===Applications of semantic wikis===
* Semantic wikis for enterprise workflows and business intelligence
* Semantic wikis for corporate or personal knowledge management
* Exchange on business models with semantic wikis
* Lessons learned (best/worst practices) from using semantic wikis or
* Semantic wikis in e-science, e-learning, e-health, e-government
* Semantic wikis for finding a common vocabulary among a group of people
* Semantic wikis for teaching students about the Semantic Web
* Offering incentives for users of semantic wikis
===Development of semantic wikis===
* Semantic wikis as knowledge base backends / data integration platforms
* Comparisons of semantic wiki concepts and technologies
* Community building, feature wishlists, roadmapping of Semantic MediaWiki
* Improving user experience in a semantic wiki
* Speeding up semantic wikis
* Integrations and interoperability of semantic wikis with other
applications and mashups
* Modeling of complex domains in semantic wikis, using rules, formulas etc.
* Access control and security aspects in semantic wikis
* Multilingual semantic wikis
If you have questions you can contact me (Yury Katkov, Program Chair),
Benedikt Kämpgen (General Chair) or Karsten Hoffmeyer (Local Chair)
per e-mail (Cc).
Hope to see you in Berlin
Yury Katkov, Program Chair
I have just closed a second deletion discussion for Property:P107 - main
As with the first discussion, it is clear that there is a broad sense
that main type (GND) is not an ideal solution, however as it stands now, a
large enough portion of the community does not want to get rid of it
unless/until a replacement system is found or developed. For this reason, I
closed the discussion as no consensus and opened up a request for comment
on the matter of finding a replacement for P107.
I have gone to the unusual step of emailing the mailing list for three
reasons. First, P107 is the most used property on the project, and it or
its replacement will (most likely) remain the most used property on the
project forever. Second, the GND has evolved into a component of how
Wikidata is structured; our lists of properties are sorted by GND type, and
that has a real impact on what properties are used on what pages. The third
reason is that, as a general statement, participation levels in requests
for comment have been downright sad. Three or four people participating in
an RfC is, for a project of this size, unhealthy, and most RfCs don't get
more than that many people participating in them. For something this
important, we need at least a dozen people, preferably at least twice that.
Anyways, the RfC is at
I hope that, with broad participation, we can finally resolve this
I'm really excited to see a sister project getting included, however I'm
concerned that the community needs a bit more time and notice (I didn't see
anything about this on WD:PC). When importing interwiki links for
Wikipedias, we had a few months before they were used on client sites. The
proposed schedule gives our bots ~3 days to import a majority of links,
which I don't think is enough time. A whole week would be much better in my
I've also started a page on-wiki to help coordinate the migration:
On Fri, Jun 28, 2013 at 2:45 AM, Denny Vrandečić <
> Sorry, I had a typo in the title of my last Email. It should be Wikivoyage
> obviously, not Wikileaks or Wikisomethingelse.
> 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.
>> * 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.
>> 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.
> Wikidata-tech mailing list
If you are running a copy of Wikibase, we have split out data model code
from WikibaseLib into a separate extension. (which can be used independent
You need to have the WikibaseDataModel extension in the extensions
directory. It will automatically be loaded by Wikibase.
If you are missing WikibaseDataModel, then you may see an error:
Fatal error: Class 'Wikibase\EntityId' not found
Additionally, the WikibaseQuery, WikibaseQueryEngine and WikibaseDatabase
components have been split into separate extensions. These are only needed
for the newest experimental query stuff.
To make things easier, Wikibase has a composer.json file to manage the
dependencies and you can use that, if you like.
Wikimedia Germany e.V. | NEW: Obentrautstr. 72 | 10963 Berlin
Phone (030) 219 158 26-0
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.
The Guidelines for sourcing statements  had a 72% support. There are
still two issues that were raised during the discussion that need to be
- Sources used in Wikipedia (templates cite doi cite book, etc): should
they be stored in Wikidata to be shared across all Wikipedias?
- Source entity type: since we now know that there is going a specific type
of item that will not have links to Wikipedia and that is somehow different
from normal items, would it be meaningful to create this new entity type?
This second issue was already discussed some time ago, but back then was
not very clear how the guidelines would look like. With the guidelines
completed, maybe now the perception has changed.
The new RfC can be found here:
While on the Hackathon I had the opportunity to talk with some people from
sister projects about how they view Wikidata and the relationship it should
have to sister projects. Probably you are already familiar with the views
because they have been presented already several times. The hopes are high,
in my opinion too high, about what can be accomplished when Wikidata is
deployed to sister projects.
There are conflicting needs about what belongs into Wikidata and what
sister projects need, and that divide it is far greater to be overcome than
just by installing the extension. In fact, I think there is a confusion
between the need for Wikidata and the need for structured data. True that
Wikidata embodies that technology, but I don't think all problems can be
approached by the same centralized tool. At least not from the social side
Wikiquote could have one item for each quote, or Wikivoyage an item for
each bar, hostel, restaurant, etc..., and the question will always be: are
they relevant enough to be created in Wikidata? Considering that Wikidata
was initially thought for Wikipedia, that scope wouldn't allow those uses.
However, the structured data needs could be covered in other ways.
It doesn't need to be a big wikidata addressing it all. It could well be a
central Wikidata addressing common issues (like author data, population
data, etc), plus other Wikidata installs on each sister project that
requires it. For instance there could be a data.wikiquote.org, a
data.wikivoyage.org, etc that would cater for the needs of each community,
that I predict will increase as soon as the benefits become clear, and of
course linked to the central Wikidata whenever needed. Even Commons could
be "wikidatized" with each file becoming an item and having different
labels representing the file name depending on the language version being
Could be this the right direction to go?