Hi.
I recently started following mediawiki/extensions/Wikibase on Gerrit,
and quite astonishingly found that nearly all of the 100 most recently
updated changes appear to be owned by WMDE employees (exceptions being
one change by Legoktm and some from L10n-bot). This is not the case, for
example, with mediawiki/core.
While this may be desired by the Wikidata team for corporate reasons, I
feel that encouraging code review by volunteers would empower both
Wikidata and third-party communities with new ways of contributing to
the project and raise awareness of the development team's goals in the
long term.
The messy naming conventions play a role too, i.e. Extension:Wikibase
<https://www.mediawiki.org/w/index.php?title=Extension:Wikibase&redirect=no>
is supposed to host technical documentation but instead redirects to the
Wikibase <https://www.mediawiki.org/wiki/Wikibase> portal, with actual
documentation split into Extension:Wikibase Repository
<https://www.mediawiki.org/wiki/Extension:Wikibase_Repository> and
Extension:Wikibase Client
<https://www.mediawiki.org/wiki/Extension:Wikibase_Client>, apparently
ignoring the fact that the code is actually developed in a single
repository (correct me if I'm wrong). Just to add some more confusion,
there's also Extension:Wikidata build
<https://www.mediawiki.org/wiki/Extension:Wikidata_build> with no
documentation.
And what about wmde on GitHub <https://github.com/wmde> with countless
creatively-named repos? They make life even harder for potential
contributors.
Finally, the ever-changing client-side APIs make gadgets development a
pain in the ass.
Sorry if this sounds like a slap in the face, but it had to be said.
Hi,
The "Other projects sidebar" beta feature is already on by default in some
projects, such as the Italian Wikipedia and the French Wikipedia. Search
for otherProjectsLinksByDefault in
http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php
Is there any reason not to make it it on by default in all (or most)
projects?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Hi,
I'm a longtime OSM contributor. I like the idea of Wikidata and what I'm
really interested in is a sort of bridge between both projects.
Would somebody be interested in writing a game like application, which
would invoke JOSM Remote Control (JOSM RC) at the coordinates in the
wikidata item and
wikidata=Q....
in the clipboard?
That would make it easier to add such tags to the OSM objects.
Polyglot
Hi,
[ Aude and Christian Consonni, this should especially interest you. ]
I was throwing around ideas with a friend about how OpenStreetMap could be
integrated with Wikidata.
The thing that I care the most in any software is internationalization.
Having a map in which all labels of towns, streets and everything else is
translated to all languages sounds like a super-wonderful thing.
Wikidata allows labeling everything, translating everything, and attaching
properties to everything, so it sounds like it could be a good match.
But then the question of "what IS everything" came up. Wikidata was created
mostly with Wikipedia in mind, so Wikipedia's notability policies
influenced Wikidata. Roughly, Wikidata has items for every thing about
which there is, or can be, a Wikipedia article and for things that are
useful, or if it "fulfills some structural need
<https://www.wikidata.org/wiki/Wikidata:Notability>".
Towns obviously have or can a Wikipedia article about them, but probably
not every street or shop. But do they fulfill a structural need or is it
way too much?
If it's way too much, how can this be bridged, or federated, or whatever
the current popular word is? I don't even know exactly how does OSM store
labels and translations now, but it sounds like another instance of
Wikibase, if not Wikidata itself, can be used for it.
I don't have much to add, but I'd love to hear ideas from people who do
(again, Aude and Christian Consonni, I'm looking at you :) ).
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Hi,
TL;DR: Did anybody consider using Wikidata items of Wikipedia templates to
store multilingual template parameters mapping?
Full explanation:
As in many other projects in the Wikimedia world, templates are one of the
biggest challenges in developing the ContentTranslation extension.
Translating a template between languages is tedious - many templates are
language-specific, many others have a corresponding template, but
incompatible parameters, and even if the parameters are compatible, there
is usually no comfortable mapping. Some work in that direction was done in
DBpedia, but AFAIK it's far from complete.
In ContentTranslation we have a simplistic mechanism for mapping between
template parameters in pairs of languages, with proof of concept for three
templates. We can enhance it with more templates, but the question is how
much can it scale.
Some templates shouldn't need such mapping at all - they should pull their
data from Wikidata. This is gradually being done for infoboxes in some
languages, and it's great.
But not all templates can be easily mapped to Wikidata data. For example -
reference templates, various IPA and language templates, quotation
formatting, and so on. For these, parameter mapping could be useful, but
doing this for a single language pair doesn't seem robust and reminds me of
the old ways in which interlanguage links were stored.
So, did anybody consider using Wikidata items of templates to store
multilingual template parameters mapping?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Hi everyone,
I'd just like to announce another experimental Wikidata SPARQL endpoint
[1], kindly provided by the folks at SpazioDati [2].
It contains both the simplified and the complete dumps, as per [3].
Each dump file is stored under a different named graph.
We are collecting the query logs, and will share the most frequent queries.
Cheers!
[1] http://wikisparql.org/
[2] http://spaziodati.eu/en/
[3] http://tools.wmflabs.org/wikidata-exports/rdf/exports/20150223/
On 3/21/15 1:00 PM, wikidata-l-request(a)lists.wikimedia.org wrote:
> On 3/20/15 2:08 PM, Markus Kroetzsch wrote:
>> >Dear all,
>> >
>> >Thanks to the people at the Center of Semantic Web Research in Chile
>> >[1], we have a very first public SPARQL endpoint for Wikidata running.
>> >This is very preliminary, so do not rely on it in applications and
>> >expect things to fail, but you may still enjoy some things.
>> >
>> >http://milenio.dcc.uchile.cl/sparql
> You have a SPARQL that provides access to Wikidata dumps loaded into an
> RDF compliant RDBMS (in this case a Virtuoso RDBMS instance). I emphasis
> "a" because "the first" isn't accurate.
>
> There are other endpoints that provide access to Wikidata dumps:
>
> [1]http://lod.openlinksw.com/sparql -- 61 Billion+ RDF triples culled
> from across the LOD Cloud (if you lookup Wikidata URIs that are objects
> of owl:sameAs relations you'll end up in Wikidata own Linked Data Space)
>
> [2]http://wikidata.metaphacts.com/sparql -- another endpoint I
> discovered yesterday .
--
Marco Fossati
http://about.me/marco.fossati
Twitter: @hjfocs
Skype: hell_j
Hey folks :)
We'll be doing another office hour on 31st of March at 16:00 UTC. See
http://www.timeanddate.com/worldclock/fixedtime.html?hour=16&min=00&sec=0&d…
for your time zone. It'll be in #wikimedia-office on Freenode IRC.
Denny and I will be there to answer questions about the Freebase move.
I'll give a short update on recent developments and I was asked to put
the RfC about admin inactivity criteria
(https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Reforming_admin…)
on the agenda as well.
Hope to see many of you there!
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/681/51985.
On 3/30/15 7:01 PM, Vladimir Alexiev wrote:
>>> We as humanity should leverage the strengths of both, to gain maximum benefits.
>> Amen! Anything less is an utter shame.
>
>>> A Little Cooperation Goes a Long Way.
>> Amen, one more time !
> Kingsley, I am very much heartened by your response because I thought you're a die-hard DBpedia guy;
> and a couple months ago when Markus pointed to the excellent Resumator, you sort of said "but does it LOD".
That's an example of how my comments can be easily misconstrued, due to
my DBpedia and LOD proximity :)
All I want is for identifiers to resolve to description documents. Net
effect, we have URIs functioning as terms rather than words and/or
phrases, expands the power of the Web.
>
> Wikidatians have strength in numbers.
> As Multichill (Sum of All Paintings, WikiCulture, WikiLovesMonuments)
> is just emailing me "We have bots and we're not afraid to use them.
> My bot (BotMultichill) has over 4 million edits"
> They're not afraid to screw some modeling up, because they're gonna fix it.
All good.
>
> They talk to each other, all the time, in sophisticated ways.
> (Well, not all of them are sophisticated: e.g. I am just learning)
> Mediawiki is the most sophisticated consensus-building platform, right?
"A" rather than "The" :)
>
> They're good with practical information architecture (things shold be easy to use and see), without being afraid of breaking some puny rule.
Yes! Not being afraid to break things is crucial. A system of draconian
rules is DOA. That said, Linked Open Data isn't draconian, but I do
empathize with those who might initially arrive at that conclusion.
> They're not afraid to use what used to be a cursed languge (PHP).
> Phabricator is a great.... 10 tools in one? I only used it couple days but the UI is excellent.
>
> And they are getting serious about RDF: they're retooling the WDQ backend because that wonderful beast is ever hungry.
> (They picked BigData because of free support and strong engagement).
>
>
> I don't quite clearly see the Complementarity between DBP and WD that you see, but there are options.
And that's the weak point that needs fixing.
Wikidata is about a crowd oriented DataWiki for structured data.
DBpedia is about Wikipedia content rendition in 5-Star Linked Open Data
form.
Wikidata enables DBpedia to be better.
DBpedia enables Wikidata to be better, even if DBpedia shortcomings are
the initial point of focus.
> What I see that there's got to be a joint series of workshops.
Yes, but not just workshops. Principals behind both projects need to
talk and get to understand one another, genuinely. As I said, these
projects are inherently complimentary+++
> Maybe also with the SemanticMediaWiki (or OntoWiki) people, because they have the third perspective.
Both are DataWiki variants. They are complimentary tools that can play a
role. Just like related tools that offer read-write capability at
Web-scale via the open standards such as LDP, SPARQL Graph Protocol,
SPARQL 1.1 Update etc..
>
> Who's for it? I sure would be happy: will cut down on travel :-)
>
> PS: Too bad this thread wont go to wikidata-l because I'm not subscribed there.
It's in the cc. :)
Kingsley
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Dbpedia-discussion mailing list
> Dbpedia-discussion(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
>
--
Regards,
Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
Dear all,
TL;DR; We are working on an *experimental* Wikidata RDF export based on
DBpedia and would like some feedback on our future directions.
Disclaimer: this work is not related or affiliated with the official
Wikidata RDF dumps.
Our current approach is to use Wikidata like all other Wikipedia editions
and apply our extractors to each Wikidata page (item). This approach
generates triples in the DBpedia domain (
http://wikidata.dbpedia.org/resource/). Although this results in
duplication, since Wikidata already provides RDF, we made some different
design choices and map wikidata data directly into the DBpedia ontology.
sample data: http://nl.dbpedia.org/downloads/wikidatawiki/sample/
experimental dump: http://nl.dbpedia.org/downloads/wikidatawiki/20150207/
(errors see below)
*Wikidata mapping details*
In the same way we use mappings.dbpedia.org to define mappings from
Wikipedia templates to the DBpedia ontology, we define transformation
mappings from Wikidata properties to RDF triples in the DBpedia ontology.
At the moment we provide two types of Wikidata property mappings:
a) through the mappings wiki in the form of equivalent classes or
properties e.g.
property: http://mappings.dbpedia.org/index.php/OntologyProperty:BirthDate
Class: http://mappings.dbpedia.org/index.php/OntologyClass:Person
which will result in the following triples:
wd:Qx a dbo:Person
wd:Qx dbo:birthDate “....”
b) transformation mappings that are (for now) defined in a json file [1].
At the moment we provide the following mappings options:
-
Predefined values
-
"P625": {"rdf:type":"
http://www.w3.org/2003/01/geo/wgs84_pos#SpatialThing"}
will result in: wd:Qx a geo:SpatialThing
-
Value formatting with a string containing $1
-
"P214": {"owl:sameAs": "http://viaf.org/viaf/$1"}
will result in: wd:Qx owl:sameAs http://viaf.org/viaf/{wikidataValue}
<http://viaf.org/viaf/viafID> .
-
Value formatting with predefined functions. The following are supported
for now
-
$getDBpediaClass: returns the equivalent DBpedia class for a Wikidata
item (using the mappings wiki)
-
$getLatitude, $getLongitude & $getGeoRss: geo-related functions
Also note that we can define multiple mappings per property to get the
Wikidata data closer to the DBpedia RDF exports e.g.:
"P625": [
{"rdf:type":"http://www.w3.org/2003/01/geo/wgs84_pos#SpatialThing"},
{"geo:lat":"$getLatitude"},
{"geo:long": "$getLongitude"},
{"georss:point":"$getGeoRss"}],
"P18": [
{"thumbnail":"
http://commons.wikimedia.org/wiki/Special:FilePath/$1?width=300"},
{"foaf:depiction":"http://commons.wikimedia.org/wiki/Special:FilePath/$1"}],
*Qualifiers & reification*
Like Wikidata we provide a simplified dump without qualifiers and a reified
dump with qualifiers. However, for the reification we chose simple RDF
reification in order to reuse the DBpedia ontology as much as possible. The
reified dumps are also mapped using the same configuration.
*Labels, descriptions, aliases and interwiki links*
We additionally defined extractors to get data other than statements. For
textual data we split the dumps to the languages that are enabled in the
mappings wiki and all the rest. We extract aliases, labels, descriptions,
site links. For interwiki links we provide links between Wikidata and
DBpedia as well as links between different DBpedia language editions.
*Properties*
We also fully extract wikidata property pages. However, for now we don’t
apply any mappings to wikidata properties.
*DBpedia extractors*
Some existing DBpedia extractors also apply in Wikidata that provide
versioning and provenance (e.g. pageID, revisionID, etc)
*Help & Feedback*
Although this is a work in progress we wanted to announce it early and get
you feedback on the following:
-
Are we going in the right direction?
-
Did we overlook something or is something missing?
-
Are there any other mapping options we should include?
-
Where should we host the advanced json mappings?
-
One option is in the mappings wiki, another one is in Wikidata
directly or a separate github project
It would be great if you could help us map more data. The easiest way is
through the mappings wiki where you can define equivalent classes &
properties. See what is missing here:
http://mappings.dbpedia.org/server/ontology/wikidata/missing/
You can also provide json configuration but until the code is merged it
will not be easy with PRs.
Until the code is merged in the main DBpedia repo you can check it out from
here:
https://github.com/alismayilov/extraction-framework/tree/wikidataAllCommits
Notes:
-
we use the Wikidata-Toolkit for reading the json structure which is a
great project btw
-
The full dump we provide is not complete due to a Wikidata dump export
bug. The compressed files are not closed correctly due to this.
Best,
Ali Ismayilov, Dimitris Kontokostas, Sören Auer
[1]
https://github.com/alismayilov/extraction-framework/blob/wikidataAllCommits…
--
Dimitris Kontokostas
Department of Computer Science, University of Leipzig
Research Group: http://aksw.orgHomepage:http://aksw.org/DimitrisKontokostas
Hey folks :)
The students team working on data quality is making good progress. For
some reason their emails don't go through to this list so I am sending
it for them below.
Cheers
Lydia
Hey :)
We are a team of students from Hasso-Plattner-Institute in Potsdam,
Germany. For our bachelor project we're working together with the team
of Wikidata to ensure their data quality.
On our wiki page (https://www.mediawiki.org/wiki/WikidataQuality) we
introduce our projects in more detail.
One of them deals with constraints, for which we need your input since
we want to work on constraints as statements on properties and the
final form of those still needs to be specified.
So far, we hope you like our projects and we appreciate your input!
Cheers,
the Wikidata Quality Team
--
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/681/51985.