Dear users, developers and all people interested in semantic wikis,
We are happy to announce SMWCon Fall 2013 - the 8th Semantic MediaWiki
Conference:
* 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
representatives, researchers.
SMWCon Fall 2013 will be supported by the Open Semantic Data
Association e. V. [1]. Our platinum sponsor will be WikiVote ltd,
Russia [2].
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
their extensions
* 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
[1] http://www.opensemanticdata.org/
[2] http://wikivote.ru
For those interested in annotation data, this is a good time to inform the
development of the Annotator framework.
SJ
---------- Forwarded message ----------
From: "Nick Stenning" <nick(a)whiteink.com>
Date: Jun 29, 2013 9:15 AM
Subject: [annotator-dev] Annotator v2.0 work-in-progress
To: "annotator-dev(a)lists.okfn.org" <annotator-dev(a)lists.okfn.org>
Cc:
Hi all,
I've pushed a branch with some very early-stage work on Annotator v2.0. I'm
focusing mainly on extracting most of the persistence logic from core
Annotator, and simplifying the Store plugin requirements through use of an
intermediate Registry object.
If anyone has any feedback, it would be gratefully received:
https://github.com/okfn/annotator/compare/master...wip
In particular, the new Registry:
https://github.com/okfn/annotator/blob/208498c/src/registry.coffee
And dramatically slimmed down Store plugin:
https://github.com/okfn/annotator/blob/208498c/src/plugin/store.coffee
-N
_______________________________________________
annotator-dev mailing list
annotator-dev(a)lists.okfn.org
http://lists.okfn.org/mailman/listinfo/annotator-dev
Unsubscribe: http://lists.okfn.org/mailman/options/annotator-dev
> http://www.wikidata.org/wiki/Q1000 is indeed an information resource
> http://www.wikidata.org/entity/Q1000 is the URI for the thing, which indeed
Apologies, I copied the wrong URI when testing!
>> Also, checking with http://validator.linkeddata.org/vapour I received
>> an error about invalid response (I am not sure whether this is a
>> problem with Vapour or Wikidata ...)
> More details would be appreciated.
Both entity:
http://validator.linkeddata.org/vapour?uri=http%3A%2F%2Fwww.wikidata.org%2F…
and wiki
http://validator.linkeddata.org/vapour?uri=http%3A%2F%2Fwww.wikidata.org%2F…
give:
* Dereferencing resource URI (without content negotiation)
** 1st request while dereferencing resource URI without specifying the
desired content type (HTTP response code should be 200): Failed
* Dereferencing resource URI (requesting RDF/XML)
** 1st request while dereferencing resource URI without specifying the
desired content type (Content type should be 'application/rdf+xml'):
Failed
** 1st request while dereferencing resource URI without specifying the
desired content type (HTTP response code should be 200): Failed
----
The graph (not the text) suggests an response of:
http: 400 Bad Request: The request cannot be fulfilled due to bad syntax
This could be vapours fault, but I fear something is wrong with
wikidata. At least the wiki test should simply find an information
resource.
Note that testing wikipedia works:
http://validator.linkeddata.org/vapour?uri=https%3A%2F%2Fen.wikipedia.org%2…
Best
Gregor
I have just closed a second deletion discussion for Property:P107 - main
type (GND).
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.
</rant>
Anyways, the RfC is at
https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Primary_sorting…
I hope that, with broad participation, we can finally resolve this
issue.
Yours,
Sven
Hi Denny,
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
opinion.
I've also started a page on-wiki to help coordinate the migration:
https://www.wikidata.org/wiki/Wikidata:Wikivoyage_migration
-- Legoktm
On Fri, Jun 28, 2013 at 2:45 AM, Denny Vrandečić <
denny.vrandecic(a)wikimedia.de> wrote:
> 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.
>
> _______________________________________________
> Wikidata-tech mailing list
> Wikidata-tech(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
>
>
Heya folks :)
Since it is almost caturday and the internet (including Wikidata) is
generally better with cats let me start with this to get you in the
right mood: http://cuteoverload.com/2013/06/25/i-got-a-peaceful-easy-feeling/
And now we can resume our normal weekly program of all things good and
excellent around Wikidata:
http://meta.wikimedia.org/wiki/Wikidata/Status_updates/2013_06_28
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.
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
of MediaWiki)
You need to have the WikibaseDataModel extension in the extensions
directory. It will automatically be loaded by Wikibase.
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/Wikiba…
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.
https://gerrit.wikimedia.org/r/#/admin/projects/?filter=Wikibase
To make things easier, Wikibase has a composer.json file to manage the
dependencies and you can use that, if you like.
--
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.
Hi all,
The Guidelines for sourcing statements [1] had a 72% support. There are
still two issues that were raised during the discussion that need to be
addressed:
- 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:
https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Source_items_an…
Cheers,
Micru
[1]
https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/References_and_…
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
of it.
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
accessed.
Could be this the right direction to go?
Cheers,
Micru