cdn.media.ccc.de/.../wikidatacon2019-6-eng-GLAM_panel_hd.mp4

Good afternoon, everybody.

Welcome to our GLAM panel.

Before we start, I just have
two announcements to make.

First of all, please extensively make use
of our Etherpad to take notes.

And the second one is directed
at our audience at home,

or wherever you are.

If you have any questions,

you can also write that into the Etherpad,

and our room angels
will keep track of them.

So, we decided that for this year's panel,

after seeing all the contributions
that were made,

we would focus on the role of Wikidata
within data ecosystems

that go beyond the actual
Wikimedia projects,

which is also absolutely in line

with the new Wikimedia
Foundation strategy.

And we have, today, four panelists.

Three plus one.

So, I would like to ask you on stage,

so we can introduce you.

So, we have Susanna Ånäs.

She's a long time free-knowledge activist

involved in many WikiProjects.

And she will be reporting today
on the project in cooperation

with the Finnish National Library.

Then we have, next to me, Mike Dickison,

who will be second in this order.

He is a museum curator from New Zealand.

He's a zoologist and a Wikipedia editor.

And he was New Zealand's
first Wikipedian at Large

in 2018 and 2019.

And he will tell us
about his experience in that role,

and what kind of role Wikidata
is starting to play in that context.

Then we have Joachim Neubert

from the Leibniz Information Center
for Economics in Kiel and Hamburg.

He has been working on making the largest
public press archives worldwide

more accessible to the public,
and he's using Wikidata to do that.

And then I will go last.
My name is Beat Estermann.

I work for Bern University
of Applied Sciences, in Switzerland.

And I've been a long-time promoter
for OpenGLAM in Switzerland and Austria.

And I will today report
about my activities in connection

with the mandate from the Canadian Arts
Presenting Association,

focusing on performing arts.

Not primarily on Wikidata,

but you will see Wikidata
is starting to play a role there, as well.

So now, most of us
will take our seat here,

and I will give the floor to Susanna.

Okay. So, hello. My name is Susana Ånäs,

and I work part-time for Wikimedia Finland

as a GLAM coordinator,

and I also do consulting
in the open knowledge sphere.

And this is a discourse,
maybe, of [inaudible].

So, I have been involved in the workings

of geographic data group of the--

well, I looked it up,
but it isn't in English,

but, cultural heritage initiative
of the Finnish royal government.

So, this is about place names

and how they are represented

in different repositories
in the GLAM sector in Finland,

and how they are trying to pull together
these different sources,

and how they are informed
by modeling in Wikidata and elsewhere.

So, here we see the three main sources
for these YSO places,

which is part of the national ontology--
general ontology.

AHAA is for Finnish archives,

Melinda is for Finnish libraries,

and KOOKOS is for Finnish museums.

So, there are three, also,
content management systems

that come together in these YSO places.

And there are exchanges between Wikidata
already taking place,

as well as the names project
for the National Land Survey.

And then, there's a third project,
the Finnish Names Archive,

which doesn't yet contribute to this,

but there are plans for that.

So, one of the key modeling issues
in this whole problem area

is that there are three types
of elements in place names

represented in this project.

One of them is the place,
the one that has location.

And one of them is the place name,
the toponym, for example.

And then, there are sources,
which are documents

from which these both can be derived from,

or like, backed up with.

The YSO places--
here, on the top right,

you will see the same diagram again.

It focuses mainly on the places.

The main thing of this
is the Finnish National Library,

and the Finto project.

There are now more than 7,000 places
in Finnish and Swedish

and over 3,000 in English,

and they are CC0 we've licensed with.

So, here you can see the service of Finto.

And a place-- I chose Sevettijärvi.

It is now also related
to our language project

with the Skolt Sami--

this is a place
in the very north of Finland

inhabited by Skolt Sámi.

So, here you can see the place
which belongs to the--

well, you will see the data
about this place.

You can see that it is connected
to a Wikidata,

as well as this National Land Survey data.

Here we go. And you will see
this in more detail, here.

It is also hierarchically arranged

inside this repository.

Well, actually,
the actual place is not seen,

but it is underneath this municipality,

as well as the region,

and Finland as a country,
and Nordic countries,

the broader region.

Here you can see that many of these

have been matched
with Wikidata previously

through Mix'n'Match,
and there are still remaining ones.

But then, the amount of names
is not that high.

It's only less than 5,000.

So, then there is this other repository

by the Finnish Geospatial
Platform Project--

Place Names Cards.

These are all the place names
that are on Finnish maps.

And they have the linked data,
which is licensed CC BY 4.0.

800,000 map labels in Finnish, Swedish,
and all those three Saami languages

that are in Finland.

And they have
two different types of entities.

The other ones are places,
and the other ones

are place names, toponyms.

And they both have persistent URIs.

Here's, for example,
the same Sevettijärvi, in first Finnish,

and then all those three Saami languages,
as well as the geographic data,

and then there is more information
about that, like the place type,

et cetera.

Here is the card for the place name,
the toponym, having its own URI.

Sorry, it seems that it's not translated
into the English list.

So, multilinguality
is not covering the whole project.

Okay, we come
to the Finnish Names Archive.

This is a project by the Institute
for the Languages of Finland,

and these represent not the places,
not the place names,

but they are actually sources for those.

So, these are three million
field notes of place names,

and it is a Wikibase project.

They are in a Wikibase,
mainly in Finnish, some in Swedish.

An outstanding collection of Saami names,
which we are very interested in.

And they are licensed CC BY.

And that is also a challenge
from the Wikidata point of view.

But if there was a Finnish local Wikibase,

we might be able to first work
on them in that project.

So, here's a screenshot of that,

showing that there's information
about the place, the maps--

the maps that the collectors
initially use,

and the card that they produce
of the information they collected.

So, here's one of those cards

broken down into data

that is included in them.

So, then they sent
this linked data project

by the Helsinki Digital Humanities Lab

and Semantic Computers,

computing group of Aalto University--

and together with this Institute
for the Languages of Finland--

the Names Sampo.

And this is an aggregated
research interface

to several place name sources.

Here you can see that many
of the sources are out there on the left,

and then, you can make
different kinds of visualizations

based on this data.

And, yeah.

So, I've been bringing up this idea
of modeling for a local Wikibase

that we could do with this data.

But when we enter
these modeling questions,

how do we model?

There are different ways,
different traditions in each of these.

And the good thing about it
is it could also serve minority languages

with very little effort.

Okay. So, here we have
the two basic options:

the SAPO model, which is
the Finnish Space-Time Ontology,

and the Wikidata model.

Here you can see
that Wikidata items tend to zero.

Ideally, they remain the same
with the changing properties.

Whereas, in the SAPO model,
these items become new

when there is a change,
such as area change and name change.

So here, come back to this division

between these three different dimensions
of places, place names.

So, should we make these place names
into entities or properties?

Wikidata uses properties,

whereas this land survey
project has entities.

Or should we make them into lexemes?

Wikidata has chosen to work
with properties,

textual properties
for place names over lexemes.

I'm sorry, the other way around.

So, the names are...

properties, not lexemes.

Right.

And maybe the shortcoming of the Wikibase

is the lack of geographical
shapes inside that--

like in the basic setup of it,

so one would have to add
more technology into the stack

to be able to use local geographic shapes.

And a federation is really needed

to be able to take advantage
of the Wikidata corpus.

So, I'm done already. Thank you.

(applause)

Okay.

(speaking in Maori)

Welcome, everyone.
My name is Mike Dickison.

And for a year,

I was New Zealand Wikipedian at Large.

You might wonder
what a Wikipedian at Large is.

Because if you actually look out for it,
there is no such thing, as we can see.

It's a term that I made up
in the grant proposal,

which the foundation
seemed to like very much.

And so, we ran with it.

So, for a year, I went through
35 different institutions,

residents, and most of them,
running training sessions,

organizing public events,
and trying to develop

a Wikimedia strategy for each one.

It was a very interesting experience,

and you encounter a wide range
of different projects and people.

And I wanted to try and talk through
some of the different projects

that dealt with Wikidata

in interesting or, perhaps,
illuminating ways,

that might be useful for folks to discuss.

The project was initially
a Wikipedia project by the name,

simply because that was what people
were familiar with,

and so we organized
multiple different events

at very traditional edit-a-thons,
gender gap work, and so forth.

[And a bunch you can see] [inaudible],

and a bunch of very successful
new editors recruited, and so forth.

We did bulk uploads into Commons.

In this case, there was a collection
of over 1,000 original artworks

by an entomological
illustrator, Des Helmore,

which had been sitting on a hard drive,

[lacking] research for ten years,

and we were able
to get clearance to release those

all under CC BY license.

So, easy wins to show to people there.

Everyone can understand
lots of pictures of beetles.

Everyone can understand workshops
devoted to fixing the gender gap.

But Wikidata
is much more difficult to sell

to people in the GLAM sector,

or anyone outside
of our particular movement.

So, I began to realize that Wikidata

was going to be a more
and more important part

of the Wikipedian at Large projects.

So, as we went through, it became
a larger and larger component

of what I was doing.

And I began to try and teach myself
more about Wikidata as well,

because I was beginning to see
how important it was.

So, this one project--

the kakapo is a native
New Zealand flightless parrot.

We worked with
the Department of Conservation,

whose job is to save
this species from extinction,

and pitched the idea,

"What if we put every
single kakapo into Wikidata?"

And that may seem ridiculous,

but it's actually
a perfectly doable project.

A few of them are in there already.

A key thing to notice here
is there are not many kakapos.

So, it's a manageable task.

There were 148 when I started,
and then one died.

And they've just had
a great breeding season up to 213.

This is great. This is the most kakapo
there have been for over 50 years.

So, this was also a big deal.

This was on the news
every day in New Zealand.

Each new one that was born--

(man) In the New York Times.

(Mike) Did it? Oh, lovely.

Yeah, this was national news.
Everyone likes these birds.

But something interesting about them

is because unlike species
that are more populous,

every single kakapo is named,
has a unique name

and a unique ID number.

And often has good biographical data

about where and when they were born,

were hatched, who their father
and mother was,

when they died, if they died.

So, there is, in fact,
a Department of Conservation database

of all this information.

And one of the most famous kakapos,
of course, is Sirocco,

who you can see is named
after a wind, was born there.

Sirocco has a Twitter account,

which Wikidata had some problems with,

because, apparently,
they just can't have Twitter accounts.

I don't know about that.

He's even featured
on an album cover, and so forth.

So there are multiple properties of this,

probably one of the most famous
individual kakapo.

So, I pitched to the Department
of Conservation,

"Why don't we try and do this
with every single one?"

And so, they had to think about
how much of the biographical data

could be made public.

And they come up with a short list.

And now we've got, I think, 212,
210--I think a couple died--

living kakapo that are all candidates now.

And they only get a name when they fledge.

They have a code number until that
while they're still babies.

So, when we've got the full-fledged crop,

we're going to create
a complete Wikidata--

the entire species will be in Wikidata.

But we need to come up
with a property for DOC ID--

I actually would like to talk
with folks about that.

Should we be using a very specific ID,

or should we be coming up with an ID

that would work for all individual birds
or plants or animals

that have been tagged
in any scientific research project?

It's a good question.

Second project was
Christchurch Art Gallery.

There are very few paintings
of Colin MacCahon,

New Zealand's most famous
artist in existence.

This is a drawing he did
for the New Zealand School Journal,

which was government-funded at the time.

So, it's actually in Archives New Zealand

who own the copyright for that.

This is a very unusual situation.

So, I worked with
Christchurch Art Gallery

who, along with Auckland Art Gallery,

maintain a site called
Find New Zealand artists.

The job of which is to keep track
of the holdings--

every institution that has holdings
of the New Zealand artist.

So, about 18,000 different artists
in their database,

and most with very little
information at all.

So, we did a standard sort of Mix'n'Match.

We did an export of the ones
that had at least a birth date,

or a death date, or a place of birth,
or a place of death.

So, that's not restricting it very much.

And even then, we were not able
to match quite a few,

but we've got about 1,500 now

that are matched
to known artists in Wikidata,

which is nice.

But what was appealing to them--

this is their website,

which really just maintains
the holdings links there.

But this biographical data,
which they create by hand, currently,

for every single artist.

And the act of exporting
and putting into Mix'n'Match

exposed numerous typos
and mistakes and such

that they haven't noticed.

And it's only when you start
running things through [Excel],

these things show up.

And the value of Wikidata
was suddenly conveyed to them

when I said, "You can just suck in
that information from Wikidata."

And that made them sit up straight.

So this, I think, is one
of the selling points.

When you have this carefully
hand-curated website

with 18,000 entries, full of mistakes,
and tell them there's another way,

that they can get other people

to do some of this fact-checking
and correction for them--

that's when it sinks home.

And then announced I was pitching the idea

that they "Wikidatafy"
this entire history book

of the New Zealand artists
in Christchurch in the '30s,

and run through--just published--
and run through every single person,

connection, place, exhibition, and such.

But it's a manageable sized project,
and they're very excited by this.

And thirdly, I wanted to show you
Maori Subject Headings.

A waka is a Maori name
for a particular kind of canoe,

a war canoe.

So, in the National Library
of New Zealand,

there's a listing for waka,
because the National Library

actually has its own dictionary
of Maori Subject Headings,

in the Maori language.

So, there it defines a waka,

in Maori and English.

But it also has a whole lot
of narrower terms,

you can see there on the side there.

a typical would be taurapa.

And a definition first in Maori,
and then in English.

It's the carved sternpost
that you can see there.

And in English, you would say "sternpost,"

but you can't use
the word "sternpost" for taurapa,

because taurapa only works
for particular kinds of war canoes.

So, there's no English word
equivalent for that.

And I suddenly realized
that here is an entire ontology

of cultural-specific terms that have been
very carefully worked out

and verified by the National
Library with Maori,

constantly being added to and improved
with definitions, with descriptions,

in both English and Maori.

Really exciting.

I suddenly thought we could put
this whole lot into Wikidata--

Maori first, and then translated
into English, as required.

Be a nice change, wouldn't it!

And here's the copyright licensing.

Unfortunately, NonCommercial-NoDerivs.

So now I have to start
the conversation with them

about why did they pick that license.

And possibly because they only got
[buy in] from Maori,

who agreed to sit down
and [inaudible] this stuff

if there was a guarantee

that none of this information
could be used for commercial purposes.

So, that's one of the frustrating
aspects of the task

is coming up against
these sorts of restrictions.

So, those are the three things
I wanted to put out in front

and sparking discussion.

Putting an entire species into Wikidata,

what it takes to actually change
an art gallery's curator's mind

about the value of Wikidata,

and what do we do when we would see
a complete ontology

in another language that,
unfortunately, has been slapped

with a restrictive
Creative Commons license.

Thank you.

(applause)

Hello. My name is Joachim Neubert.

I'm working for the ZBW,

that is, Information Center
for Economics in Hamburg,

as a scientific software developer.

And one of my tasks last year
was preparing a data donation to Wikidata.

And I want to give some report on this
on our first experiences

from donating metadata
from the 20th-Century Press Archives.

To our best knowledge,

this is the largest public
press archive in the world.

It has been collected
between 1908 and 2005,

and has been got from

more than 1,500 newspapers
and periodicals

from Germany, and also internationally.

And it has covered everything
which could be of interest

for the Hamburg,

the Hamburg businesspeople

who wanted to expand over the world.

As you can see, this material
has been clipped from newspapers

and put onto paper,

and then collected in folders.

Here you see a small corner
of the Person's Archive,

and, similarly, information
has been collected on companies,

on general topics, on wares,
on everybody,

on everything which could be interesting.

These folders have been scanned

up to roughly 1949.

by the DFG-funded project in 2004 to 2007.

As a result, up to now,
it was 25,000 thematic dossiers

of this time.

This contained about 2 million,
or more than 2 million pages.

And these are online.

This application developed
at that time by ZBW,

which now looks a bit outdated,

not so fancy,
and what’s more of a problem.

It's an application which was built
architecturally on Oracle,

it was built on ColdFusion,
it runs on Windows servers,

so it's not very sustainable
in the long term.

And we have discussed
should we migrate this

to a more fancy linked data application,

or should we take a radical step

and put all this data in the open.

We have assigned CC0 license to that data

and, currently, moving some main--

access layer, some main discovery layer--
so it's a primary access layer

to the open linked data web,

where it actually makes most sense

to put some metadata into Wikidata,

and to make sure that all folders

of the collections are linked to Wikidata,

so they are findable,

and that all metadata about these folders

is also transferred to Wikidata.

So it can be used there,
and it can be enriched there, possibly.

Corrections can be made to that data.

What is still maintained by ZBW is,
of course, the storage of the images,

which we can't put in any way,

or we can't give a license on that

because this was owned
by the original creators.

But we make sure that they are accessible

by some, again, metadata files
via DFG Viewer

in the future by IIIF manifests.

And we will prepare
some static landing pages

which will serve as a data point
of reference for Wikidata,

as well as still making available data

which doesn't fit well into Wikidata.

[For us] is migration
and data donation to Wikidata

with our custom infrastructure

of SPARQL endpoint with that data,

and we basically used federated queries

between that endpoint
and the Wikidata Query Service

to create according statements

through [eyes of] concatenated

in SPARQL queries themselves,
or transformed via a script,

which also generated references
for the statements.

And then put that into QuickStatements
of the code to use this online.

So, this is what we get.

It's not only simple things
like birth dates, but, sorry--

but also complex statements

about already existing items,

like this person was a supervisory
board member of said company

during this period of time,

and referenced for use in...

in the scientific context.

The first part of this data donation
has been finished.

The Person's Archive
is completely linked to Wikidata.

And this is also an information tool.

A lot of items which have been before

not had any external references.

And we had about more
than 6,000 statements,

which are now sourced
in this archive's metadata.

Well, this was the most easy part,

because persons are easily
identifiable in Wikidata.

More than 90% already existed here,

so we could link to that.

We created some 100 items for these,

for the ones which were missing.

But now, we are working

on the rest of the archive,

particularly on the topics archive.

Which means mapping a historic system
for the organization of knowledge

about the whole world,

materialized as newspaper
clippings to Wikidata.

To give you a basic idea,
the Countries and Topics archive

is organized by a hierarchy of countries

and other geographic entities,

which is translated to English,
which makes this more easy.

And German deeply nested...

deeply nested classification of topics.

And this combination defines one...

one folder.

So, what we now want to do
is to match this

as a structure to Wikidata,
and to bring the data in.

And I want to invite you

to join this really nice challenge

in terms of knowledge organization.

So, it's a WikiProject
where this work is tracked,

and you can follow this
or participate in this.

And, yes, thank you very much.

(applause)

So, we're taking
performing arts to Wikidata.

And we're taking performing arts
to the linked open data cloud,

by building a linked open data
ecosystem for the performing arts.

And the question I'm trying to answer,

and I hope you'll help me
in answering the questions

which place for Wikidata and all that.

But let me first start with my experiences

which I made this year,

the first half of the year,
when I had the pleasure

to work with CAPACOA,

which is the Canadian Arts
Presenting Association,

which actually launched a project
called Linked Digital Future Initiative,

to actually get the entire art sector
in Canada to embrace linked open data.

And they did that based on the observation

that over the past five years,

the [inaudible]-- the important topic
within performing arts

was the fact that metadata
was not around in sufficient quality

and not interlinked, not interoperable.

And that was why some of the performances,

some of the events
are not so well findable

by Google and by personal
computer-based assistants, and so on.

So, the vision we kind
of developed together

is that we want to have a knowledge base

for many stakeholders at once.

So we looked at the entire
performing arts value network,

we identified key stakeholders in there,

we looked at the usage scenarios
that we like to pursue,

and we kind of mapped it
to the whole architecture

of such a knowledge base,
or of the different platforms in there,

which, obviously,
is a distributed architecture,

and not one big monolith.

I'm just going to run
through that quite quickly

because we have ten minutes each.

But I think we'll have plenty of time
tonight or tomorrow to deepen that

if anybody's interested in the details.

So, we started from
that Performing Arts Value Network,

which, interestingly,
was just published last year.

So, we're lucky to be able
to build on previous work,

like you have the primary value chain
of the performing arts in the middle,

and various stakeholders around that.

All in all, we identified
20 stakeholder groups,

which then we kind of boiled down
into seven larger categories

for each of the stakeholder groups.

We kind of formulated what kind of needs

they would have in terms
of such an infrastructure,

and what would they be able to achieve
if the whole thing was interlinked

and the data was publicly accessible.

And so, you can see the types here,

the different types is Production,
then Presention & Promotion,

Coverage & Reuse, Live Audiences,

Online Consumption, Heritage,

Research & Education.

And after kind of setting up a big table,

of which you can see
just the first part here,

we kind of compared [over there],
had a look at which type of data

were actually used across the board

by all different groups of stakeholders.

And there's quite a large basis of data
that is common to all of them,

and that is really is the area

where it makes a lot of sense, actually,
to cooperate and to keep that--

to maintain the data together.

So, when talking about
platform architecture,

you can see that we have four layers here.

At the bottom, display the data layer.

Of course, Wikidata plays a part in it,

but also a lot of other databases,
distributed databases

that can expose data
through SPARQL endpoints.

The yellow part in the middle,
that's the semantic layer.

It's our common language
to describe our things,

to make statements about things
around the performing arts, the ontology.

Then we have an application layer

that consists of various modules,
for example, data analysis,

data extraction-- so, how do you
actually get unstructured data

into structured data--

how can we support that by tools.

Then, obviously, there's
a visualization of data--

so if there are large quantities of data,
you want to visualize it in some way.

And on the top, you have
the presentation layer,

that's what the ordinary people
are actually interacting with

on a daily basis--

search engines, encyclopedias,
cultural agendas,

and a variety of other services.

We're not starting from scratch.

Some work has already
been done in this area.

I'll just cite a few examples
from a project

which I have been involved in.

Some other stuff going on as well.

And so, I started in this area

with the Swiss Archive
of the Performing Arts.

[Until] building a Swiss
Performing Arts database,

we created the performing arts ontology,

that's currently being
implemented into RDF.

And there we have the database
of like 60, 70 years

of performance history in Switzerland.

So, that's something that can build on,

and that's something
that's been transformed into RDF.

And there was a builder platform
where this data can be accessed.

Then we have done
several ingests into Wikidata,

partly from Switzerland,

partly also from
the performance arts institutes,

for example, Bart Magnus
was involved in that.

He was the driving force behind that.

There's also stuff from Wikimedia Commons,

but not very well interlinked
with all the rest of our metadata.

And obviously, by doing this ingest,

we also kind of started to implement
parts of this Swiss data model

into Wikidata.

Then one of the Canadian
implementation partners

is Culture Creates.

They're running a platform that actually
scrapes information from theater websites,

and inputs it into a knowledge graph,

to then expose it to search engines
and other search devices.

And there again, we kind of had
to implement and extend this in ontology.

And as you can see from the slide,
is that there's so many empty spaces,

but there's also some overlap,

and an important overlap, obviously,
is the common shared language,

which will help us actually interlink
the various data sets.

What is also important, obviously,

is that we're using the same
base registers and authority files.

And this is a place where Wikidata
plays an important role

by kind of interlinking these.

Now, I'd like to share the recommendations

by the Linked Data Future Initiatives
Advisory Committee.

At least the two first recommendations.

So, for the Canadians,
now it's absolutely crucial

to kind of fill in their own Canadian
performing arts knowledge graph,

because unlike the Swiss Archive
of the Performing Arts,

they're not starting
with an already existing database,

but they're kind of
creating it from scratch.

And it's absolutely crucial
to have data in there.

And second, as you can see,
comes in already Wikidata.

Wikidata, by the Advisory Committee,

has been seen as complementary
to Artsdata.ca, this knowledge graph,

and, therefore, efforts should
be undertaken to contribute

to its population
with performing arts-related data.

And that's where we're going to work on
over the coming months and years,

and that's also why
I'm kind of on the lookout here

to see who else will join that effort.

So, right now, obviously,
we're saying they're complementary.

So, we have to think about whether
the pluses and the minuses

of each of the approaches.

And you can see here a comparison

between Wikidata and the Classical
Linked Open Data approach.

I would be happy to discuss
that further with you guys,

how your experiences are in there.

But, as I see it, Wikidata is a huge plus
because it's a crowdsourcing platform,

and it's easy to invite further parties
to actually contribute.

On the negative side, obviously,
you get this problem of loss of control.

Data owners have to give up control
over their graphs, data quality,

and completeness.

It's harder to track on Wikidata
than if you have it under your control.

And the other strength of Wikidata

is that it requires immediate integration
into that worldwide graph.

And you kind of just do it--

kind of reconcile step by step
against other databases,

which may also be seen by some
as an advantage,

but of course, if you're looking
for integration and interoperability,

Wikidata forces you to go for that
from the beginning.

And then, obviously, harmonizing
data modeling practices

is an issue in both cases.

But it may seem, at the beginning,
easier to do with just in your own silo,

because at some point,
you're done with the task,

and it would be
an ongoing task on Wikidata.

So, when it now comes to prioritizing
the data to be ingested,

that's like the rules
I kind of go by at the moment.

First of all, we'd like to ingest it

where it's unclear who would be
the natural authority in the given area.

So that's definitely data
that will be managed in a shared manner.

And we'd like to ingest it where we see

a high potential
for crowdsourcing approaches.

We'd like to ingest data where the data
is likely to be reused

in the context of Wikipedia.

And there's also hope that some part
of the international coordination

around the whole data modeling,
about the standardization,

they could actually take place
directly on Wikidata,

if it's not taking place elsewhere,

because it kind of forces people
to start interacting

if they ingest data in the same part.

And we'd like to focus now next
on base registers and authority files

because they kind of help us
create the linkages

between different data
and uncontrolled vocabularies

as an extension of the existing ontology.

So, just two more slides.

The next steps will be that we're taking
the sum of all GLAMs approach

to Wiki Loves Performing Arts.

That means we're describing
venues and organizations,

and try to push the data to Wikipedia

in forms of infoboxes
and [bubble] templates.

And the other one, the other projects
I'm going to pursue is COST Action

that we'll submit next year

around that Linked Open Data Ecosystem
for the Performing Arts.

COST is a European program
that supports networking activities,

and the topics to be covered
are listed here.

Two of them, I have highlighted--

one of them is like the question
of federation between Wikidata

and the classical linked
open data approaches.

And the other one, I think,
is very important also,

where we have a huge potential still,

is implementing international campaigns
to supplement data on Wikidata.

So, that's it. Thank you
for your attention.

Now, I would like to ask
my colleagues up here.

To the panel, maybe you'll get them
microphones as well.

And then I would like to...

give you the chance to ask questions.

And obviously, also ask my colleagues

whether they have questions to each other.

So, do we have maybe a question
from the audience?

(man) [inaudible]

I would like to ask from each of you

where would you draw the line,

basically, how you define--

when do you need to run your own Wikibase,

and what do you want to put on Wikidata?

Like, is this a clear delineation
of what is seen

behind of putting it [into order.]

I can answer first because I have the mic.

So, I've been thinking
that one of the issues is notability.

I'm addressing that
in a different project.

And I think licensing could be one,

because you can apply your own terms
in your own database,

and then I think wherever it's possible.

And then, the third one
is just to have it as a sandbox,

prepare it for ingestion into Wikidata.

These are the three main things
that I come up with now,

but I can come up with more.

For me, rights are always
going to be an issue.

So, if the National Library
wanted to move towards Wikibase,

that would enable them to continue
to control the licensing

for the work they've done
with Maori language terms.

The kakapo database only contains data

that the Department of Conservation
felt could be made public,

but I suspect if they see it
up and running,

they might be tempted
to use a private Wikibase

to maintain their own database,

simply because of some
of the visualization tools

that could be applied might be better

than the sort of Excel spreadsheet system
that they currently run.

Well, I think this very much depends
on the kind of data.

We are, with the Press Archive, of course,
in a quite lucky position,

in that this was material
which was published,

it was published at the time,

but it was expensive to publish.

So, this is quite easy.

I think, also, projects--

and this is a typical project,

so it was funded for some time,
and then funding ended,

and what happens with the data
which is enclosed in some silo,

and some software
which will not run forever.

And so, it makes
absolute sense in my eyes.

At the time, Wikidata
wasn't around, but now it is,

and it makes absolute sense
for our project to early on

discuss sustainability in the context
of how could we put this

into a larger ecosystem like Wikidata,

and discuss this with the data community

what is notable and what makes sense
to add this to Wikidata,

and what makes sense to keep this
as a proprietary form.

Maybe in a more simple form
than sophisticated application,

but make it discoverable
and make it linked to the large data cloud

instead of investing lots of money

into some silo which will not sustain.

Yeah, as I said before
in the project I was presenting here,

are dualities between Wikidata
and classical linked open data approaches.

So, it's not so much about
setting up a private Wikibase.

Like one challenge we have had,
and, of course, in Wikidata,

is that when we ingest
your own data there,

you also have to do some housekeeping

of people, of other people, actually.

And they can put off people,
[or it also means] that we will address it

just step by step.

So, there will be, at the moment,
a database living--

in classical linked open data

and we're starting to linking it
with Wikidata,

and it's a continuous process to find out

for which areas the most data
will be eventually on Wikidata,

and for which areas it will actually
live on other databases.

Obviously, we'll have challenges
regarding synchronization,

as we probably all have,

because that linked data field,

where we still have
to negotiate who we trust,

who has authority about what.

(assistant) Other questions?

(woman) Thank you.

So, fully agree with that issue of--

where to put the boundary
between why do we put data on Wikidata,

or why do we keep them,
and create, manage, and maintain them

in local databases and for what purposes.

And I think that
this is a large discussion

that goes beyond just the excitement

of putting data on Wikidata
because it is public,

because it serves humanity, because--

while there are two cool tools,

and things are more complicated
in real life, I think.

Well, despite this,
it's quite an interesting discussion.

And then this is another issue, also,
or another problem that is being discussed

in this event in different panels.

It is on one side, have your own database,

whatever the technology is

and publish things on Wikidata,

or build your own system

of creating and managing information

on the Wikibase technology.

And then, synchronize or whatever--
do federation or things,

so it's a matter
of technology that is used,

and the fact that you use Wikidata
just for publishing,

or the infrastructure
that is underneath Wikidata

to create and manage your data.

I mean, we had a discussion

about the Wikibase panel,

and there will be other discussions here,

but things are
on different levels, I think.

Maybe [you sort of get] to that discussion
about Wikibase or Wikidata--

I think it's problematic
that we are focusing so much

on this Wikibase infrastructure,
because there are other infrastructures,

like in the area of performing arts.

We have another complementary community,
which is MusicBrainz

that runs on their own platform
that provides linked open data,

and as I understand it,

there's agreement
within the Wikidata community

that we're not going
to double all their data--

we're not going to copy all their data,
but we accept that they're complementary.

So, what will happen when you start
integrating this data in Wikipedia?

Infoboxes, for example.

Would we be able to pull that data
directly from their SPARQL endpoint?

Or would we be obliged
to kind of copy all the data,

and what kind of processes
are involved in that?

(woman) Discussions are open, I think,

because within this event,
you have both interested communities--

those that are interested in Wikibase,

and those that are interested in Wikidata,

and those who are interested in both.

Yeah, but we're not going
to oblige them to move to Wikibase.

- (woman) Not necessarily.
- MusicBrainz is not running on Wikibase.

(woman) No, I just wanted to say
that you have separate problems,

sometimes interrelated,
sometimes not completely separated.

And I had another question or remark

regarding the management of hierarchies
in controlled vocabularies,

like thesaurus, like you in Finto.

You do have the places

in the Maori

Subject Headings,

Well, they have to deal with
the management of concepts in hierarchy.

What is your take, your opinion

about the possibility
of managing this controlled

knowledge organization
systems in Wikidata?

I think in the case
of Finto and YSO places,

the repository will be a collection

of several sources, eventually.

So, it is in flux, anyway.

So, we don't have to necessarily--

well, I don't represent
the National Library,

but in that possible project,

we would not have
to maintain an existing--

or fight with an existing structure.

So, in that sense, it is an area
open for exploration.

The Maori Subject Headings
seems to lend themselves ideally

to Wikidata structure,

but the licensing,
of course, forbids that.

I suspect that if the licensing
were different

and they were put into Wikidata,

as soon as somebody decided
they didn't like the hierarchy

and started to change things,

there would be an immediate outcry
from people who worked very hard

to create that structure

and get the sign-off
from various different Maori

that was the current hierarchy.

So, that's an issue to try and resolve.

I think in terms of knowledge
organization systems,

they are all different.

And I'm not sure
if it would be a good idea

to represent different hierarchies
in Wikidata as such,

but it maybe makes sense
to think about overlays

of the data.

So, to do mappings on the content level.

For example, as ZBW partnership
Thesaurus for Economics.

And this thesaurus has its own hierarchy,

and, of course, it would be possible
to project the hierarchy

of this thesaurus into Wikidata concepts

without actually storing
this kind of structure

as an alternative structure
within Wikidata

which would make a lot of confusion.

But I think we should think
of Wikidata, also, as a pool of concepts

which can be connected on layers
which are outside,

and which give another view of the world

which is not necessarily to be
within Wikidata.

(assistant) Alright. Some other questions?

Otherwise-- okay.

(man 2) Joachim, I just wanted
to follow up on that last point.

So, these layers, as you picture it,

they would be maintained externally

and somehow integrated

with Wikidata from the Wikidata side,

or have you thought a bit further

about how that might be managed?

Actually, no, I have no--

I have done experiments
with ZBW and Wikidata.

I was [inaudible] here at Wikidata.

But I think this is
a whole new complex thing,

and so, it's up to [discuss],
[to give up a lot of control]

to do such things.

But it has to be figured out.

Should we take one more?

(man 3) Ah, great.

I was just wondering
about the kakapo project.

Uh-hmm.

(man 3) Okay. So, did you get
any pushback from the Wikidata community

about having individual animals
out of those items?

Not so far.

(man 3) Has anyone heard
about this before?

Is it "not so far" because
no one has heard about it yet?

There's been a small discussion
for quite some time now--

those people interested
in this sort of thing in Wikidata,

and we all seem to think
that it's a natural extension

of getting individual Wikidata items
to a famous racehorse

or someone's cat, which--
that's modeled pretty well.

I guess just the audacious thing
is putting the entire species in there.

But I think it's perfectly manageable.

(man 3) Don't try it with cats and dogs.

(laughter)

(assistant) Okay. I think
the time is finished.

Thank you very much for attending.

I think the speakers will be still open
for the questions and a break.

And have fun.

Thank you very much.

(applause)