*36C3 preroll music*
Okay so now to our speaker, he’s Lucas. He's a SPARQL magician I'm told, so and he
will introduce you to his favorite querying language, SPARQL, and give you a
little introduction and in the second part he will do some live coding which is
always really interesting and funny and you can give him some things that he's
querying for you and I'm sure we'll have lots of fun and interesting learning stuff
here so give a warm round of applause to Lucas.
[Applause]
[inaudible]
Is this better? Aha! It's a bit too loud so I'll just talk a bit until they have
figured it out. Yeah so this is going to be kind of two parts but not really that
separate but in the second part I'm basically going to write the queries that
you suggest so if you – if you see what I'm going to do here and then think oh I
have a great idea for something we could perhaps query then just remember that and
we'll get back to that hopefully because otherwise the second half is going to be
really short if I don't get any ideas from you. But yeah, so this is about querying
linked data which allows you to do all kinds of crazy things and answer all kinds
of crazy questions such as I think I had on the slides something like "what are the
largest cities with a female mayor?" and if you wanted to find that out
traditionally you could like go through Wikipedia and try to find all the largest
cities and see which ones have a female mayor and which ones don't or perhaps
there's a category with all the cities with a female mayor but then you have to
sort them by population and it's a whole mess and with linked data you can find
that out much more easily and also all kinds of other things but let's start with
some simple fantasy linked data so this is a tiny snippet of linked data, some data
graph. It's just composed of a load of nodes which are these ovals and rectangles
here and they're connected with arrows and each of these forms kind of a triple
consisting of the start node and then the arrow and then the end node and that's how
we represent all the information you have in there, in this linked database. So for
example we can read this as this talk right now happens in the Esszimmer or the
dining room which is the name of this stage here and it's going to be followed
by the live querying session which also happens in Esszimmer and the live querying
session in turn follows this talk again and the Esszimmer, the dining room, is
next to the kitchen, the Küche, and the kitchen is next to the dining room again
and both of them are part of the WikipakaWG which is part of 36C3 and the
talk happens right now and at the same time there's also some talk about how
state elections are climate elections or something in the Chaos West stage, starts
at the same time, Chaos West stage is part of the Chaos West Assembly which is part
of 36C3 as well and so this graph has a few important properties, for example
there's some redundant connections here, you could see, you could say, if this talk
is followed by the live querying then you don't really need to know that live
querying follows this talk, it's kind of redundant information. You already know
it, but it doesn't hurt to have it, and it often makes your life easier if you have a
little bit of redundancy in your graph and then if you find that one half of this
connection is missing for example you can still investigate what's going on and also
in here we have kind of bi-directional connection so Esszimmer is next to Küche
which is next to Esszimmer but this is two separate arrows and could also be that
only one of them is there so you don't have arrows which go into-, in both
directions at once in this data model, it has to be, if you want something like this
you have to have two separate arrows because that keeps the data model very
simple. You just have subject predicate object and that's everything you have, and
then to query this graph, you kind of select a tiny part of it and then you
remove some part that you don't know about for example we know that this talk is
followed by live querying and if we remove the live querying part, then we can ask
something like... Okay, I did it the other way around. Never mind, this way. This
talk is followed by which talk? and then you have a question but because you've
left out this part and then if you ask this question to a query service it can,
kind of, you can think of this like a, err, damn, I only know the German word for
this one, a, Schablone, template, so you put this over the graph and this has to
match the existing node this has to match the existing arrow and then you see which
nodes can you put in here and in this case that's only the live querying or the other
way around which talk follows this one so you can have the beginning of the triple
can be a variable like this one or the end of the triple can be a variable like in
this case and you can also have more complicated patterns like, no there's not
a more complicated pattern, this is the same pattern. You have the question which
talk happens in Esszimmer and you have two answers: this talk happens in Esszimmer
and live querying happens in Esszimmer. But you can also combine more graph nodes
like this, for example, which talk happens in some room, which is part of the
Wikipaka-WG. So we have one free part here and one free part here. But we know that
these two have to be connected with, "happens in", and then this has to be
connected with "is part of" to the Wikipaka-WG. And you can kind of
construct– if you can phrase your question as a kind of graph like this, where some
parts are predetermined that you already know about and the other parts that you
want to find. Those are these kind of variables which are here indicated with
just dashed lines. Then you can ask that question to the graph and find the
matching results. In this case, you have these two matches, this talk happens in
Esszimmer as part of Wikipaka-WG and live querying happens in Esszimmer, is part of
Wikidata– Wikipaka-WG. And then, if you– if we had more information in this graph
here, we might also have other rooms. For example, there's this library over there
which also is going to have some talks. If we had the whole schedule in here, we
would find those as well. And we could also adapt the query so that we don't even
make the Wikipaka-WG part fixed. We could ask for anything that happens in 33C3. So
that would be some variable, happens in some room, is part of some assembly, is
part of 36C3. And then we would find this thing as well because it fits the same
kind of pattern: happens in, is part of, is part of 36C3. Does that make sense?
Hopefully. I'm seeing a lot of nodding heads. OK, that's great. So then we can
try to move ahead to actually ask some of these questions to a real query system.
Because in reality, you're not going to actually draw these graphs, but you have
some kind of language where you phrase them instead, which looks a bit like this.
So you have the part: SELECT anything WHERE, that is kind of like SQL, and then
everything else is not like SQL. Forget SQL! I hear this is easier to understand
if you don't know SQL. I didn't know SQL that much when I learned SPARQL, and I
think it helped me, apparently. But what you write down here is these, is this kind
of description of the graph, and these dashed parts, which are the variables
which you don't yet know. Those are marked with a question mark because that's kind
of what you use to ask a question. In this case, I've just called it "?talk", but it
could be any name, basically. And then instead of "happens in" as two words, I've
just written "happensIn" as one and then with the prefix "36C3" and it happens in
the 36C3 Esszimmer because I don't really have a separate dining room at home, but a
lot of people do. So if we just wrote it happens in Esszimmer, that would be pretty
ambiguous and no one would know which which dining room you're talking about.
And by adding this prefix we know we're talking about just the dining room in
this, at thirty– 36C3. I think, I assume there's no other assembly that has
something called the dining room. If it does, then we would have to add something
else here to make it clear. And I've used the same prefix for "happensIn" to make
clear which kind of "happens in" relation we're talking about, that it's one
specific to Congress events. And then you could ask this to a query service which
has this example graph in it, and you might get the response that it's these two
talks. And at the end, you have this period here because if you read the whole
thing, it's kind of like a sentence again. Because the talk happens in Esszimmer. And
if you have two sentences, then you have two periods. So the talk happens in some
room. And this room is part of the Wikipaka-WG. And because we've used the
same variable name here and down here, this has to be the same room. And it
couldn't just be two different things. So if we use two different variable names
here, room and something else, then we would just get all the combinations of
talks happening somewhere and rooms being part of Wikipaka-WG without them being
connected anyway, but because they use the same variable name they have to be
connected like this. And then you would get these results we've seen earlier. What
you can also do is leave out the room. So when I translate this into English, I
could say, the talk happens in the room and the room is part of Wikipaka-WG. But I
could also say the talk happens in *some room, which is* part of the Wikipaka-WG,
as kind of a– I don't know what that's called in English kind of a relative
sentence sub-something-clause where we don't really talk about the room in itself
just as a part of this larger sentence. And you can write that in SPARQL as well.
And then it looks like this. And these square brackets kind of describe what the
room looks like without giving it names. So in this case, you can only select the
talk up here and we don't have a room variable. But if you don't care about what
the room is, then that can be very useful. I've also changed something else here.
I've replaced the 36C3 in "isPartOf" with schema, which is another prefix and schema
is kind of this collection of useful prefixes and other nodes that you can
reuse, for example, if you're describing things you have on your website, you might
say you have an article with a schema:title and a schema:publicationDate.
So this was mainly introduced by Google and some other search engines. But we can
use the same vocabulary to talk about our talks because "isPartOf" is one of these
standard terms we can use for that. And what else do I have. OK, the next thing I
have is actual queries. So I think I'm just going to– I'm almost going to switch
to Wikidata, so I should talk a bit about Wikidata. So all these examples here were
just on some example graph, which I made up here and threw on a slide with a lot of
probably overengineered tikz LaTeX magic, which I shouldn't have wasted that much
time about. But it looks nice. And… but if we want to write real queries, we could
load this thing into a query service, but it wouldn't be that interesting because
it's kind of small. But there are a lot of real data graphs out there that you can
query with this query language, SPARQL. And one of the coolest ones, at least in
my opinion, is called Wikidata or Wikidata. There's some kind of discussion
about how it's pronounced. And it's kind of a free database of anything that's
relevant. And it's part of the same family of projects as Wikipedia and Wikimedia
Commons and other things. And it's also maintained by the same community of
volunteers. And you can find all kinds of really interesting and cool and funny data
there. So all of these example queries, which I have here, we're just going to ask
to Wikidata. But first, I will just give you one or two minutes to try to imagine
what this question would look like, either in the graph format or in the SPARQL
format. Just try to figure out how you would formulate: "which software is
written in bash" as a kind of, this kind of graph query. And then we can see what
we can come up with. So. I didn't think this through. I need some waiting loop
music now. Does anyone have a kind of idea of what the graph looks like, because I'm
going to uncover it now and then you can compare, if it looks the same way. So it
would look like, this at least using the Wikidata terminology. So instead of "is
written in", the property is called probing– programming language. And this
could also, this could be called "bash" or "Bourne Again Shell" or "GNU bash" or
something. Doesn't really matter. And in SPARQL, it looks like this, which is a lot
less readable, unfortunately, because one of the things about Wikidata is that it's
multilingual. So instead of saying "programming language", we say "P277". And
I think that's beautiful, haha. No, but this is a property ID and you can look up
what this property is called in English or in German or in any other language. So if
we look at Wikidata.org and look for – I think I forgot to zoom in. Yeah. There we
go. I hope that's readable. Property P, what was it? 277. That is the property
"programming language", at least in… okay, you can't read that. There you go. At
least in English. In German it's "Programmiersprache", and it has tons of
other languages too. So you can use Wikidata in any language you want, which
is very nice. I could also show this page in a different language and then all of
this would look different. The downside is that the SPARQL query is not quite as
readable because you have to use all these numeric identifiers, but you don't have to
memorize them at least. So let's… oops, try to write this query. SELECT * WHERE
and we have the software, which is… which has the programming language "bash", and
then we have to add these prefixes first, so bash is going to be a Wikidata item. So
we abbreviate that with "wd" and that's a prefix. And then if I press control space,
or I think on Macs command space works as well, then it searches for bash and shows
me these suggestions and then I can just select the right one. In this case, "GNU
bash", and then I have the ID, and if I move the mouse over it again, then I can
see what this ID refers to. So it's not quite as bad as– so on the PDF slides, you
just see the ID. But if you're actually on the query.wikidata.org website… let me
make that a bit larger so you can all see it. And if you want to try that out on
your laptop, I don't know, here it's a bit *audio outage* And for the programming
language, we use a slightly different prefix, which is "wdt", which stands for
"truthy". So we're only interested in "truthy" information and not all the
information. And then we find this property P277. And if we run this query
with control-enter or with this button here, then we get a collection of other
IDs. Yeah. Does anyone want to get software which is written in bash? This
one has a very low ID that is going to be… Loading. There we go. Autopackage. Some
package management system that I haven't even heard of, but it's written in bash.
OK, so… wait. Er, so here you can see all these statements and "programming
language: GNU Bash" is the one we looked for. And unfortunately… so this is not a
very useful list. So one thing we can do in the Wikidata Query Service, which is
pretty specific to Wikidata, is to add the so-called label service, which is
basically magic that you don't need to understand. But you write something like
"serv" or "service" and then with control+space again for autocompletion.
And it suggests you this thing. And you just keep that in your query at all times,
basically. And then you say, I would like to have not just a software, but also the
software label. And then we get down here, the label of the software. And I can also
add the software description. And then we also see what, what is described. At least
if it has a description and then the query results are already a lot more usable. And
I'm just going to rename this to "item" and then we can edit this query however we
want and the variable name will always kind of match. Because the next query
won't be about software anymore. So it'll be confusing if you just still call it
"software". But, yeah, there is some software here like Apache Yetus, Ruby
Version Manager, Wikidata missing pictures, Pi-hole, all written in Bash.
OK, I have several more examples queries here, which are kind of simple, should I
skip ahead or is it good if I do a few more simple examples. Skip ahead? Is that
OK? OK, then let's. So who was born at sea is not all that interesting. Just Place of
birth at sea. We have a special value for that and it's not a very interesting list.
I think a few results, just five or so, because most people are going to have
"place of birth: Atlantic Ocean" or something. Which places are located on the
White Elster, just something for the Leipzig people. And where does the
Neverending Story take place? This actually kind of cute. Let's do that.
Also, this is a bit interesting because in this case, the variable is in the last
place and not the first one. So that… and then we have the Neverending Story in the
beginning and narrative location. And then the item is at the end instead of at the
beginning of a triple. And it works just as well, except that a lot of these don't
have a label in English. So let's add German as a fallback language. And then we
get all of these places which someone added to Wikidata at some point. Let's see
if there's any useful information about them. So they all have IDs in the same
range. So it looks like they were all created at the same time because the are
are just increasing all the time. So the Gelichterland is a place from the
Neverending Story, it's a finctional… fictional country. It has a capital, which
is this fictional place. It's located on the… this terrain feature, it's present in
the Neverending Story. And it depicts horror fiction. I'm not sure about that,
but let's leave it alone for now. OK, yeah. And skip to a slightly more
interesting query, which is this one, which popes had children. So what is the
graph going to look like for this? How many, how many triples are we going to
have? So triple is node, arrow, and another node, how many triples would you
need for "Pope has a child"? Let's do a raising hands. Who thinks you need zero
triples, OK? Who thinks you need one triple? Who thinks you need two triples?
That's more people. Does anyone think you need three triples? No. OK, so mostly two,
but some people think one. So the one… the people who think it might need one triple,
perhaps are thinking of something like the Pope, which is the leader of the worldwide
Catholic Church, has a child, this child or it's called item, but that's not going
to have any results. Or it could be the other way around. And you could say that…
oh let's just comment this out. The item has "father: the pope". And that doesn't
work. Because the items are not… the children are not directly connected to the
item for the office of the pope, instead it's going to be two levels. It's going to
say the child has a father, some person, and then the person has the office pope or
has the position pope or is a pope or something. So you need this level of
indirection. So in the graph that looks either like this or it could be the other
way around. So either the child has a father pope, which has "position held:
pope" or the pope has a child and also a "position held", so that's kind of an
example of the redundancy I mentioned earlier, we have the two directions
"child" and also "father"/"mother", and- so you can ask your query in two ways, and
it doesn't really make that much of a difference, assuming that the data is
complete. And I think someone occasionally runs queries to check if any of these
circles are missing. So let's try one of them, let's just stay with this one, so
the item does not have "pope" as father, it has some pope, and then this pope has
"position held: pope". And then let's add the "pope" label and… yeah, pope label is
enough, and then we get 24 results! So we have a Duke of Parma which, who was the
son of Paul III. Paul III had three children. Let's sort by this. Wow,
Alexander VI was very busy. And some of them just have, oh oh oh, we have
duplicates, Giovanni Borgia and Giovanni Borgia. Should I demonstrate Wikidata
editing now or do we just ignore this? So, yeah, someone imported a lot of
information from this peerage database and apparently we have some duplicate items
here, let's just leave those alone for now. In fact, I think this and this also
looks suspiciously similar. Giovanni Borgia, unless he had two children of that
name. I mean, he could have. So this… we have a date of birth 1470s… 1498. No, that
might actually be different children. OK, not a very creative father in the names.
Yeah. And wait, that's a pope who's a child of another pope. Very interesting!
And another one. And another one. We have three popes who are children of other
popes. Let's search for those! So we would also need for that, that the item has
"position held: Pope", and I could copy paste this, but just do this. So the item
should be… child should have a "father: pope" and the item should have "position
held: Pope", and the pope should also have "position held: pope". And in this case,
it would probably be less confusing to call these "child" and "father", because
this is also a pope now, but… variable names. One of the three hardest problems
in computer science, right? Yeah, we have three children who are… three popes who
are children of other popes. Wow. I'm actually going to save this query, popes
who were children of other popes. But actually, we can future-proof this a
little bit, because right now we've only said that the father should be a pope. But
in case there's ever a female pope, let's just switch this around and say that the
pope should have the child… item and then it's going to work, even if the pope
happens to be female and is a mother instead of a father. There we go, same
three results. OK, and let's keep that, and open a new tab for next queries. Yeah.
Which Microsoft software runs on Linux. OK. That's not that funny. So perhaps we
can just skip it… I don't know. That joke kind of ran out of steam a while ago.
Basically looks like this and it's like Visual Studio Code and three other
programs, meh. What are some compositions for organ and orchestra. This isn't funny
at all, but I just find it very nice because it's just an awesome sound. And so
that would be… the composition has the instrumentation "organ" and also
"orchestra", which we can write as… item, item label… composition… instrumentation,
this one, orchestra. And also, "composition… organ". And then, oops,
yeah, this should be "item"… and also I forgot to add the label service. There we
go. And we have 12 results, which is nice if you want to listen to any of those. We
could also check if any of them have an audio file on Commons. Let's see. One, OK,
and I think we've heard this one already. So, but… one thing that's kind of annoying
here, I should have mentioned this in the last query, I think. So I had to repeat
the item and the property ID, which is a bit annoying and makes the query difficult
to read. And what you can do is leave that out and you can also do this in the
previous case. So let's actually go one slide back. So here I didn't write twice
that it's the software which should have the developer, and also the operating
system. I just wrote the software has "developer: Microsoft" and also with a
semicolon at the end instead of a period, it has "operating system: Linux". So if
you read this as English it's just one sentence where you don't repeat the
subject twice. The software has "developer: Microsoft" and "operating
system: Linux", instead of "software has developer: Microsoft" and "software has
operating system: Linux". And if you… if the property here is also the same thing,
then you can even leave that out and add a comma at the end and just list the two
values and you don't even have to repeat the instrumentation. So let's do that here
and abbreviate this query. And it has the exact same 12 results, just slightly more
convenient to read and… to write at least, hopefully also to read. I don't know. But
you don't use the comma that much. The semicolon is pretty useful, like we could
have written this as, the pope has, er, the child and also position held like
this. It means exactly the same, but you can immediately see that both of these
refer to the pope because there's just a bunch of blank space here. Yeah, so then
we have this one. This isn't funny at all, but there are a lot of people who used to
be in the Nazi Party during World War 2 and then who later just went back into a
civil life and even received the Bundesverdienstkreuz, the order of merit
of the Federal Republic of Germany. And you can find those… in this case I've done
it with three triples, which is, the person was a member of this political
party and received this award. And also I've added that they're "instance of:
human", because we also have a lot of fictional data on Wikidata. You already
saw that with the Neverending Story stuff earlier. So there might also be a
fictional character who was a member of this political party and who received the
award, and we're not really interested in those. So we add "instance of: human", and
then we are certain that we only get real results and not fictional results. And it
doesn't really cost us anything because the Query Service can optimize that pretty
well. So let's write that… actually, let's do that here. So the item should be
"instance of: human", which is Q5, because it's a very common item, and "member of
political party". And you can see I can search by the German abbreviation and find
this, even though it's not a label, because there are search aliases. And also
"award received", the Bundesverdienstkreuz, because I can't be
bothered to type in the whole English name. There we go. And we find, I think…
how many results? Eleven results. Yeah. And this actually isn't quite correct,
because in theory, you don't get this order, this order has like 11 parts or
something. You can get the Grand Cross with Distinction or you can get the Star
or whatever. I think it's listed somewhere here. Yeah, you can get the Grand Cross
Special Class, you can get the Grand Cross Special Issue, you can get the Grand Cross
First Class, blah blah blah. And so, in theory, any of these people should have
one of these awards and not just "order of merit". But I think when I checked, all of
them just had… all the results, just had directly "order of merit". But actually,
no we can try to search for the correct ones instead. So it would not be part of
this directly, it would be… "award received" would be some award, such as
this one, and then this award is part of the order of merit, so "award"… "part of"…
Let's see if that finds any results. Oh. Oh. Oh, dear. Yeah, that, that… that's a
lot of results. "Herbert von Karajan". That's that's depressing. OK, yeah. OK, so
I think I… when I tried this out and didn't find any results, I just did
something wrong because, this way we find a lot more results. And if we… so we don't
actually select the award here, because we don't care what kind of award they got. So
we could also use this abbreviation again, like this. So we just say they got some
award, which is part of the order of merit. And in this case, we could even
abbreviate that further and say, we put a slash here. And then, that kind of
describes a path that you have to take from this item to this item and you have
to first get to some award received. And then that has to be part of something
else. And you can add as many elements here as you want. And then we get the
exact same 802 results… and… lots of well- known names here. And if we want to find
the original 11 ones that directly had the order of merit as the award received, we
can add a question mark here, which is just like in a regular expression, it says
this part is optional. They can have directly received this award or they can
have received some award, which is part of the order of merit. And then we should get
813. Yeah, 813 results, so 802, plus the 11 from earlier. And… I'm starting this
with "instance of: human", which… and the Query Service is going to re-order this
because searching for all the humans and then filtering for the ones who are in
this political party and so on wouldn't be efficient. So I don't have to worry about
that. I could write it in this order, or I could shuffle it around. Doesn't make any
difference. The Query Service already knows in which order to do these things.
So you don't have to worry about that. You can just start with "is a human" and then
add everything else. I think I have one more complicated query here. Yeah, so
that's one of the examples I mentioned earlier, the largest cities by population
with a female mayor. So the graph for that is, I think the largest one I prepared for
the slides, except the one in the beginning. And it looks like this. We
should have a city which is a city, "instance of: city", and it has a certain
population, and it has… so for the mayor, we use the same property as for head of
government. And if you don't know that, you could look at some city like Berlin
and maybe you know what the mayor of Berlin is called… what was it?. Something
"Müller", I think. Yeah. And then you can see, aha, the property for the mayor is
"head of government". Or you could also search for, the city should have a mayor,
and then you'll still find "head of government", the right property. And that
mayor should be a human and she should have the gender "female". Oops. There's a
question mark there for no reason at all. That's not a variable. That should be the
fixed value. Sorry. So let's put that there. We have a city which is "instance
of: city", and it also has a population which we're going to use later and it also
has a head of government. No, that's wrong. Not the "office held by head of
government", the "head of government" itself, which we call the mayor and then
the mayor is "instance of: human" and gender should be female… come on… female.
And let's select the city, cityLabel, mayorLabel and also the population. And
then we find some 83 results. That's not yet the largest cities with a female
mayor. That's just all of them. And in Wikidata we know about 83, apparently. And
if your local hometown has a female mayor, just go ahead and add it to Wikidata and
it's probably relevant. It's not– So the relevance criteria are not as strict as on
Wikipedia fortunately. But if we want just the most populous ones, we can go a bit
back into SQL land and say we want to ORDER BY the population and in SQL you
would write DESC afterwards and in SPARQL it's different. You write
DESC(?population). Erm, I think it's nicer that way. But perhaps it would have been
nicer to just stick with the SQL syntax. I don't know. And we want to limit this to
just the ten most populous cities, for example. And here we go. Tokyo is
currently the biggest one, then Hong Kong, Baghdad, Surabaya, Rome. Yeah. And, oh.
This doesn't make that much sense, Caracas has two mayors. Anyone… yeah, exactly. So
we're only supposed to get the current mayor. Head of government… yeah. Does
anyone know which one is the current one? Or we could just check Wikipedia… Caracas,
which hopefully doesn't get it's information from Wikidata yet. So it's not
circular. And the mayor is… Carolina, Carolina Cestari… Cestari, I don't know.
*laughter*
OK, so let's add a new one. Ah…? Doesn't have an item yet, is that… is that the
mayor, or is chief of government something else? Doesn't occur anywhere else on the
page, of course. Local government… mayor… no. OK, so let's just… I don't know,
doesn't she have a Wikipedia article? No. Just appears in some lists and then she
doesn't have a Wikidata item yet? No. Then… I don't know. We'll do some live
Wikidata editing. It wasn't part of this talk, but let's just do it. Carolina
Cestari… what country is that? Venezuela. Venezuelan politician, and that sounds
like a female name, so I'm just going to guess and check that after the talk. So
she's definitely a human. And gender is female and that is going to be enough for
our query. Do this search again. There we go. And set this to preferred rank. So
that's how the Query Service knows that this is the current value and it should
only return this one. And ideally, one of the head of government values should have
this preferred rank to mark it as the correct current value. And then all the
other ones are additional data that you can use if you want. But it's not the main
value and we are not going to get it in a simple query. And then there's some error
because Caracas isn't some kind of political territorial entity and it should
have a start time. I don't care right now. OK, so we run this query again and
hopefully get just one result for Caracas this time. No. Uhm, we have to wait a bit
until the Query Service is updated. Because it's kind of asynchronous. It just
keeps watching for changes and eventually it will get the new data, but… okay. It
might take a bit longer. Anyways. That's how that query works. Does that make kind
of sense? OK, great. Yeah, I think this is almost exactly what I wrote here. Yeah.
Except with some labels and the label service. Yeah. There is one problem here,
which is, for example, I happen to know that Mexico City is a very large city with
a population of… population: almost 9 million. So it should be right after Tokyo
in front of Hong Kong. And the head of government is a Claudia Sheinbaum or
something, which sounds like a woman. So we should get this result in the query.
The reason we don't is that Mexico City is an instance of "big city" and we have
searched for "instance of: city". And there's some debate about does this class
even make sense at all? I think this is actually the German classification of, a
big city is one with 100 000 Inhabitants, and in other languages or countries, a big
city might be something else, but for now that… the data is what it is. Fortunately,
what we have here is the information, a "big city" is a subclass of a city/town,
which is a subclass of "locality", which is a subclass of. Wait. We should arrive
at city at some point, but I think we've already gone past that. It's also an
instance of capital. Let's go down that instead. A capital is a subclass of city,
there we go. So if we can tell the Query Service to follow these subclass
connections, then we should find these cities. And one way to do that… to make it
work for Mexico City would be to say, it has to be "instance of", some, with the
path again, "subclass of: city" and then we would find Mexico City, but we would
not find all the… oh, we would still find Tokyo because it's still a capital, I
guess. But we've missed a lot of other cities, I think which we used to have…
yeah. Rome, for example, is gone. Because it's… that's just an instance of city
directly. And we've now made the subclass mandatory. What we should do is make it
optional, or even better, we would– we should say there can be any number of this
element. So there… it can be an instance of city or it can be an instance of a
subclass of city, it can be an instance of a subclass of a subclass of city. You can
follow any number of elements, that what this… that's what this star means, just
like in a regular expression. And then we probably have to say we only want the
distinct ones because they are like five different ways to go through the subclass
tree until you've found "city". And we're not interested in the different ways. But
now we should get Tokyo and Mexico City. And Rome is also here and Caracas is
completely gone because we found enough other cities which we were missing
earlier. So you kind of have to watch out and sometimes use elements like this…
"subclass of"-tree is pretty common, or with a, something… order of merit, we had
to use this "part of". You have to watch out if the results are plausible, or
ideally, you know some item that should be in the results, and then you check, is it
there? Why is it not there? And investigate like that. But that's a fixed
version of the query. And… yeah, if we were not interested in the mayor, we could
do the same trick again. But, yeah. It doesn't make that much of a difference.
And I think… yeah, that was almost the only difference. Yeah, except that I
removed the population so we can order by a variable that you don't select in the
end if you want. And I think I am out of slides. So, yeah, if you want to see more
queries, you can look at these Twitter or social media accounts. There's a huge list
of example queries on Wikidata, which is so big that it's getting too big for a
wiki page, and people had to move some queries out there and it's kind of just
grown since 2015 or something. And there's a lot of garbage there, but also a lot of
useful queries if you want to look at that. And I had two more queries in the
talk description which we haven't talked about yet, and I think we have the time. I
can just try to open these. "Which films starred more than one future head of
government?" Does that work? It doesn't. Can I copy the URL here? Yeah, copy link
address. So that's a kind of longer query, which is why it didn't really fit on one
slide. But the important film is you have… er, the important part is you have some
film… instance of, or subclass of film, it has a publication date and a cast member,
which is the head of government. And the head of government held some position,
some head of government, er, some subclass of head of government. And that should be
after the film was published. And then you get a bunch of results. I think this takes
like 11 seconds or something. And you get like films with Schwarzenegger and one
other actor who became US governor. I don't remember the name. And you also get
a lot of… or several films from World War II with future French heads of government,
which is really cool. So, like a film that was shot about the liberation of Paris,
where it's… it's kind of a stretch to call them cast members, but they're definitely
in the film. And if we get the result, then I can tell you what the film is
called. Yeah, it might be busy right now, so you get up to 60 seconds in the Query
Service and then in the end your query is killed if it takes longer than that. So
sometimes it can be a bit of a struggle to make the query work within 60 seconds.
There we go, 50 seconds. That was close. So there's yeah, there's a "La Libération
de Paris" with Charles de Gaulle, who was president of the Council and president of
the provisional government, and also Georges Bidault, I think, who was prime
minister and president of the Council, and other stuff. We have several Indian films
with people who went on to become chief ministers. And then down here there's some
Canadian politicians, apparently. And then here's Arnold Schwarzenegger and Jesse
Ventura, who both became governors and also starred in several films. And the
other thing was, we have a lot of data about the British government because a lot
of volunteers have just been slaving away at that data and adding and adding more
information. I think they've… they have all their parliaments, complete with party
affiliations and everything for at least the last 100 years and some partial data
for a lot more than that, because they have a very long parliamentary history.
And then you can do queries like "how many people named John are there in
parliament", and "how many women with any name". And you can see when the women were
finally more than just the men who are named "John". And it's kind of an amusing
graph. Or not so amusing. Takes a while as well. I hope it doesn't take 50 seconds,
but it looks like the Query Service might be busy at the moment. But I think it was
something like in 1991 or so is the crossover point. Oh yeah. And I should
mention anyway, so everything we saw right now was just a lot of tables. But you can
also show results in different ways, such as a line chart. There we go. So in 1992,
this was the first parliament which had more women than Johns. And then the Johns
have slightly declined and the women have gone up to 220. How many people are in the
House of Commons in total? Does anyone know? No. So I don't know what percentage
this is. Uh, but, this was… yeah, this latest election from 12 December already
in there. Yeah. *indistinguishable*. What? So the query looks like this. So this one
is broken into several parts. We first find all the members of parliament, so
they should be human, again, no fictional people, and then they should have some
"position held", which is a subclass of "member of parliament" in the House of
Commons. And then there should also be, um, a parliamentary term on that, so that
we know which parliament it is and when it starts. And then down here, we import all
those MPs and filter for just the ones with the "given name: John". And then we
filter for just the ones with "gender: female". And there's an optional "subclass
of" in here, because currently the data model is that there is a separate item for
transgender female and someone can have "gender: transfemale– transgender female",
which is a subclass of "female". And there is a discussion right now to get rid of
that and have a separate property for that instead. And then all the trans people
just have "gender:", their right gender, and you don't have to mess with subclass.
But right now we still… well, we need it in theory, I don't think there are any MPs
in practice. But, you know, you know, you can just keep it in there. And then we
import the results and get them here either as a line chart or as a table, if
you want to sort it by the time… yeah, the data starts in 1919, apparently. So we
have exactly a hundred years of history there. We can also show it as a bar chart,
if that makes more sense. No it doesn't. That makes no sense. Line chart is the
right one. Oh, right, but if you show the line chart again, then it breaks for some
reason, there's some bug there. So let's just show it again. There we go. That's
the right… chart. Yeah, and I guess… oh wow, it's already… 50 minutes, so I guess
this is the point where we start moving to the live querying part, and I was told I
should make at least a short break for the stream, so the Angels know where to cut
between. But we could also take a 10 minute's break and then start the next
talk on time. Does that sound OK? Or is 10 minutes too long? Uhm, if you're going to
stay here, which would be very nice, then please think of some example queries that
you think we could write, and then I can try to write them, because otherwise I'm
not going to have much to do. But yeah, let's do a 10 minute break and see you
then. Thank you so far.
*Applause*
*Postroll Music*
Subtitles created by c3subtitles.de in the year 2021. Join, and help us!