What is the relation between WikiData and Wikipedia info boxes?
- Which is the source of the other?
- Is the data synced among them?
I wondered where the dumps of the Wikidata sites table went. It used to
be part of the exports, but now it's gone. New name? Different system?
In the latter case: where do I now find the language, page URL, file
URL, and group for sites that Wikidata links to?
Faculty of Computer Science
Technische Universität Dresden
+49 351 463 38486
I posted this last week to wikidata(a)lists.wikimedia.org, but perhaps
this is a better forum for this problem. Re-posting it here.
Federated queries are disabled on the stand-alone code out-of-the-box.
I followed the advice on this post to un-disable federated queries for
my local installation:
(Thanks Mr. Malyshev!)
I did have one problem with the build: I found myself having to remove
the checkstyle plugin from the pom.xml file to get the maven build to go
Now on my local installation I can get this query to work just fine:
(Current namespace: wdq)
Bind ("Algeria"@en as ?countryLabel)
(current namespace: test)
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
Bind ("Algeria"@en as ?countryLabel)
?country rdfs:label ?countryLabel.
But this query (and every variation I could think of) unfortunately
(current namespace: wdq)
prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
Bind ("Algeria"@en as ?countryLabel)
?country rdfs:label ?countryLabel.
This is also the case when addressing a Jena service I have set up on a
I would appreciate any guidance you could give me.
Thanks and regards,
Very interesting topic,
Would love to learn more about geo coding with Wikidata,
or maybe even about spatial modeling or creating significant improvements
into desired gazeteers &/or geodatabases. Ofcourse, I am not familiar with
much of the .rdf output,
but maybe we can talk about those summarized efforts towards retreiving
spatial attributes using
the Wikidata API >? (SPRQL).
On Fri, Apr 8, 2016 at 10:34 AM, <wikidata-tech-request(a)lists.wikimedia.org>
> Send Wikidata-tech mailing list submissions to
> To subscribe or unsubscribe via the World Wide Web, visit
> or, via email, send a message with subject or body 'help' to
> You can reach the person managing the list at
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Wikidata-tech digest..."
> Today's Topics:
> 1. Re: MathML is dead, long live MathML (Thomas Douillard)
> 2. Re: MathML is dead, long live MathML (Peter Krautzberger)
> 3. Re: MathML is dead, long live MathML (Roger Martin)
> 4. Fwd: [Wikidata] upcoming change in RDF format data
> (Daniel Kinzler)
> Message: 1
> Date: Fri, 8 Apr 2016 14:11:13 +0200
> From: Thomas Douillard <thomas.douillard(a)gmail.com>
> To: Wikidata technical discussion <wikidata-tech(a)lists.wikimedia.org>
> Subject: Re: [Wikidata-tech] MathML is dead, long live MathML
> Content-Type: text/plain; charset="utf-8"
> Hi, One concrete usecase is the formula datatype for properties on
> Wikidata. We are discussing the semantics issues here : what means the
> operators of the formula, what means the variables ? An immediate way, in
> Wikidata, is to
> In the item for a geometric figure, for example a square, how to model that
> a square can be defined in the euclidian space by the geometric coordinates
> of points, we could create the item for a point class in Wikidata, give a
> name of a point (pretty much usual mathematical or programming work) and to
> link that variable name to an item for the semantics/corresponding type.
> Same for the operators.
> Last, in the question you raised on "modelling maths versus modeling domain
> model formula" I'd say that in Wikidata the scope is basically unlimited,
> contrary to a regular scientific publication who takes place in a context
> that may be more or less non formally explicited, we can fill the gap
> beetween more formal aspects of logical or inference rules used by the
> scientist, the mathematical framework (euclidian space, non euclidian
> space, logical framework, axioms ... we pretty much have items for all of
> this and can create new one if that's structurally needed for a usecase)
> and the formula. Time is less of an issue because the work is reusable and
> cumulative, there is no deadline. There is only a need to leave the door
> open to do that work for someone to be able to do it at his/her convenance.
> Of course it's a lot of work, but there is no pressure. I'm not sure how
> MathML relates to this however.
> 2016-04-08 0:51 GMT+02:00 Paul Topping <pault(a)dessci.com>:
> > Peter just posted a follow up response, largely commenting on my
> > https://www.peterkrautzberger.org/0187/.
> > First, I suspect the reason his post doesn't get as much discussion as
> > he'd like is because his blog doesn't accept comments. I can understand
> > he doesn't enable comments on his personal blog but why not post it
> > somewhere that DOES accept comments?
> > He says that most of the discussion has been private. That is not the way
> > to change a standard or replace it by a new one. By all means have your
> > private conversations but don't expect others to agree with any
> > reached in them. The result of good ideas expressed in private
> > should be to introduce them into public conversation. Instead, his post
> > treated MathML's failure as a fait accompli. Perhaps it is but only in
> > narrow scope of it being ignored by browser makers.
> > He feels that many things I said in my reply were more about expressing
> > own ideas. I'll cop to that. I felt that was needed to indicate that
> > are other points of view and other ideas. His solutions may not be the
> > right ones. Let's open up the discussion.
> > Can we identify specific topics worthy of addressing and discuss them? I
> > tried to hint at some possible directions in my reply, which is why it
> > veered into some of my own ideas. I would love for this to be a
> > constructive discussion. Instead of discussing whether MathML is a failed
> > standard, I would like to see real, open discussion on solutions to
> > problems. Any takers?
> > Paul
> > > -----Original Message-----
> > > From: Paul Topping [mailto:email@example.com]
> > > Sent: Thursday, April 07, 2016 2:02 PM
> > > To: Daniel Kinzler <daniel(a)brightbyte.de>; Moritz Schubotz
> > > berlin.de>; www-math(a)w3.org; Peter Krautzberger
> > > <peter.krautzberger(a)mathjax.org>
> > > Cc: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>;
> > > <wikidata-tech(a)lists.wikimedia.org>
> > > Subject: RE: MathML is dead, long live MathML
> > >
> > > I have no problem with that but are some of these lists members-only? I
> > was
> > > told when I replied that my message would be reviewed by the moderator
> > > I wasn't a member. Perhaps that was the W3C list.
> > >
> > > Paul
> > >
> > > > -----Original Message-----
> > > > From: Daniel Kinzler [mailto:firstname.lastname@example.org]
> > > > Sent: Thursday, April 07, 2016 11:06 AM
> > > > To: Moritz Schubotz <schubotz(a)tu-berlin.de>; www-math(a)w3.org; Peter
> > > > Krautzberger <peter.krautzberger(a)mathjax.org>
> > > > Cc: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>;
> > wikidata-tech
> > > > <wikidata-tech(a)lists.wikimedia.org>
> > > > Subject: Re: MathML is dead, long live MathML
> > > >
> > > > Am 07.04.2016 um 20:00 schrieb Moritz Schubotz:
> > > > > Hi Daniel,
> > > > >
> > > > > Ok. Let's discuss!
> > > >
> > > > Great! But let's keep the discussion in one place. I made a mess by
> > > > cross-posting this to two lists, now it's three, it seems. Can we
> > agree on
> > > > <wikitech-l(a)lists.wikimedia.org> as the venue of discussion? At
> > for
> > > the
> > > > discussion of MathML in the context of Wikimedia, that would be the
> > best
> > > > place,
> > > > I think.
> > > >
> > > > -- daniel
> > > >
> > > >
> > _______________________________________________
> > Wikidata-tech mailing list
> > Wikidata-tech(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
Rather than discussing whether MathML is a failed standard, web or otherwise, I recommend we discuss specific, constructive topics. I suggest the discussion be in the context of MathML where appropriate, not because I want to defend MathML but because it is an existing standard. It is a place to start. If the solutions we reach replace MathML all or in part, so be it. Let's not start by throwing it out but by addressing its problems. We can certainly create a new standard if MathML can't be fixed. Finally, if this is the wrong venue for this topic or any other, please suggest a better one. If there are other parties that need to know about the discussion, please let them know.
Assuming others agree, let’s start with perhaps an important issue. Should Presentation MathML dictate a specific rendering or leave formatting choices up to the renderer. Peter says, "I have the impression people generally expect consistent rendering across browsers. But anecdotal evidence is, well, anecdotal." I would agree with this statement. People do expect this. I believe they get that expectation from TeX but it does make sense. Why would a user want a different rendering in a different browser?
The reason I said "no" to this before was because the MathML spec leaves a lot of rendering decisions up to the implementation. Someone reading the MathML spec should NOT expect all renderings to be the same. In fact, the spec doesn't specify the rendering at the required level of detail. Doing so would be difficult. TeX doesn't specify its rendering in detail either except via the code itself. In other words, the only proper rendering of TeX is that done by TeX itself.
We could create a MathML 4 in which the graphical rendering is specified in writing and in detail. Implementations would be constrained much more than by the current spec. Another way to achieve this goal is to create a reference implementation. This would be the TeX way, or close to it.
We could even map MathML onto TeX somehow and then defer to TeX's rendering. The MathML spec would be annotated by TeX templates (perhaps macros) that serve to define the rendering. The reference implementation would consist of a MathML-to-TeX convertor and the TeX engine itself. Implementations that intend to abide by the MathML 4 spec could use the reference implementation or roll their own.
When I say rendering above, I only mean graphical rendering. When we talk about audio or braille rendering, things are much less clear. The state of the art in MathML-to-speech has certainly not reached a point where everyone can agree. Besides, there is personal taste of the reader and multiple languages to consider.
Ok, I'll stop there and take a breath.
Just a quick heads up that this is expected to go live next week. Since nobody
responded to the original announcement, we don't expect much trouble.
But if you are processing WKT literals from Wikibase RDF output, you need to
check the version number, and parse the literals accordingly.
-------- Weitergeleitete Nachricht --------
Betreff: [Wikidata] upcoming change in RDF format data
Datum: Sun, 3 Apr 2016 11:02:04 +0300
Von: Stas Malyshev <smalyshev(a)wikimedia.org>
Antwort an: Discussion list for the Wikidata project. <wikidata(a)lists.wikimedia.org>
Organisation: Wikimedia Foundation
An: Discussion list for the Wikidata project. <wikidata(a)lists.wikimedia.org>
We are committing a patch that implements a change in RDF format output,
specifically how we output coordinates as WKT points.
If you do not use RDF format exports and specifically WKT coordinate
literals there, this change has no effect for you.
When we first implemented it, we chose to make it "Point(latitude
longitude)". Unfortunately, turns out the standard way in WKT is
Point(longitude latitude) and that's how most of the tools that
implement WKT format understand it. In general, geo-data formats are
split on this question, see http://www.macwright.org/lonlat/. But WKT is
pretty universally in lon-lat camp, so we have to follow the established
As such, we are changing the WKT representation and we are bumping the
format version (reported as schema:softwareVersion on RDF dumps/exports)
from 0.0.1 to 0.0.2 so that the tools could adjust properly.
See more details in: https://phabricator.wikimedia.org/T130049
Wikidata mailing list
Peter Krautzberger, maintainer of MathJax, apparently thinks that MathML has
failed as a web standard (even though it succeeded as an XML standard), and
should be removed from HTML5. Here's the link:
It's quite a rant. Here's a quick TL;DR:
> It doesn’t matter whether or not MathML is a good XML language. Personally, I
> think it’s quite alright. It’s also clearly a success in the XML publishing
> world, serving an important role in standards such as JATS and BITS.
> The problem is: MathML has failed on the web.
> Not a single browser vendor has stated an intent to work on the code, not a
> single browser developer has been seen on the MathWG. After 18 years, not a
> single browser vendor is willing to dedicate even a small percentage of a
> developer to MathML.
> Math layout can and should be done in CSS and SVG. Let’s improve them
> incrementally to make it simpler.
> It’s possible to generate HTML+CSS or SVG that renders any MathML content –
> on the server, mind you, no client-side JS required (but of course possible).
> Since layout is practically solved (or at least achievable), we really need
> to solve the semantics. Presentation MathML is not sufficient, Content MathML
> is just not relevant.
> We need to look where the web handles semantics today – that’s ARIA and HTML
> but also microdata, rdfa etc.
I think both, the rendering as well as the semantics, are well worth thinking
about. Perhaps Wikimedia should reach out to Peter Krautzberger, and discuss
some ideas of how math (and physics, and chemistry) content should be handled by
Wikipedia, Wikidata, and friends. This seems like a cross roads, and we should
have a hand in where things are going from here.
-- daniel (not a MathML expert all all)
The primary sources tool can add references to existing claims. For some
reason, it started re-adding the claim yesterday instead.
Did anything change on the Wikidata-side in the last few days that could be
causing this change in behavior? Or should we look harder on the Primary
Bug is being tracked here:
IEEE DSAA'2016: Third International Conference on
Data Science and Advanced Analytics
October 17-19, 2016
The submission Web site for DSAA'2016 is https://easychair.org/conferences/?conf=dsaa2016.
Paper Submission deadline: Friday 20 May, 2016, 11:59 PM PDT
Notification of acceptance: 15 July, 2016
Final Camera-ready papers due: 19 August, 2016
All accepted papers will be published by IEEE and included in the IEEE Xplore Digital Library.
The conference proceedings will be submitted for EI indexing through INSPEC by IEEE.
Top quality papers accepted and presented at the conference will be selected for extension and
publication in the special issues of some international journals, including IEEE TKDE, ACM TKDD,
ACM TIIS and WWWJ.
Data driven scientific discovery is an important emerging paradigm for computing in areas
including social computing, services, Internet of Things, sensor networks, telecommunications,
biology, health-care, and cloud. Under this paradigm, Data Science is the core that drives new
researches in many areas, from environmental to social. There are many associated scientific
challenges, ranging from data capture, creation, storage, search, sharing, modeling, analysis,
and visualization. Among the complex aspects to be addressed we mention here the integration
across heterogeneous, interdependent complex data resources for real-time decision making,
streaming data, collaboration, and ultimately value co-creation. Data science encompasses the
areas of data analytics, machine learning, statistics, optimization and managing big data, and
has become essential to glean understanding from large data sets and convert data into actionable
intelligence, be it data available to enterprises, Government or on the Web.
Following the previous two successful editions DSAA'2014, DSAA' 2015, the 3rd IEEE International
Conference on Data Science and Advanced Analytics (DSAA' 2016) aims to provide a premier forum
that brings together researchers, industry practitioners, as well as potential users of big data,
for discussion and exchange of ideas on the latest theoretical developments in Data Science as
well as on the best practices for a wide range of applications.
DSAA is also technically sponsored by ACM through SIGKDD.
DSAA'2016 will consist of two main tracks: Research and Applications. The Research Track is aimed
at collecting original contributions related to foundations of Data Science and Data Analytics.
The Applications Track is aimed at collecting original papers (not published nor under
consideration at any other venue) describing substantial contributions related to Data Science and
Data Analytics in real life scenarios. DSAA solicits then both theoretical and practical works on
data science and advanced analytics.
Topics of Interest -- Research Track
General areas of interest to DSAA'2016 include but are not limited to:
* New mathematical, probabilistic and statistical models and theories
* New machine learning theories, models and systems
* New knowledge discovery theories, models and systems
* Manifold and metric learning, deep learning
* Scalable analysis and learning
* Non-iidness learning
* Heterogeneous data/information integration
* Data pre-processing, sampling and reduction
* High dimensional data, feature selection and feature transformation
* Large scale optimization
* High performance computing for data analytics
* Architecture, management and process for data science
2. Data analytics, machine learning and knowledge discovery
* Learning for streaming data
* Learning for structured and relational data
* Intent and insight learning
* Mining multi-source and mixed-source information
* Mixed-type and structure data analytics
* Cross-media data analytics
* Big data visualization, modeling and analytics
* Multimedia/stream/text/visual analytics
* Relation, coupling, link and graph mining
* Behavior, change, dynamics and variation modeling and analytics
* Personalization analytics and learning
* Web/online/social/network mining and learning
* Structure/group/community/network mining
* Cloud computing and service data analysis
3. Storage, retrieval and search
* Data warehouses, cloud architectures
* Large-scale databases
* Information and knowledge retrieval, and semantic search
* Web/social/databases query and search
* Personalized search and recommendation
* Human-machine interaction and interfaces
* Crowdsourcing and collective intelligence
4. Privacy and security
* Security, trust and risk in big data
* Data integrity, matching and sharing
* Privacy and protection standards and policies
* Privacy preserving big data access/analytics
* Social impact
Topics of Interest -- Applications Track
Papers in this track should motivate, describe and analyse the use Data Analytics tools
and/or techniques in practical application as well as illustrate their actual impact.
We seek contributions that address topics such as (but not limited to) the following:
* Best practices and lessons
* Data-intensive organizations, business and economy
* Quality assessment and interestingness metrics
* Complexity, efficiency and scalability
* Big data representation and visualization
* Business intelligence, data-lakes, big-data technologies
* Large scale application case studies and domain-specific applications, such as but not limited to:
* Online/social/living/environment data analysis
* Mobile analytics for hand-held devices
* Anomaly/fraud/exception/change/event/crisis analysis
* Large-scale recommender and search systems
* Data analytics applications in cognitive systems, planning and decision support
* End-user analytics, data visualization, human-in-the-loop, prescriptive analytics
* Business/government analytics, such as for financial services, socio-economic activities,
culture, manufacturing, retail, utilities, telecom, national security, cyber-security,