Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/439 Thanks!
So we welcome you want us
back this talk attribution
revolution, give a big hand of applause
and say yes,
thank you very much.
Thank you all for braving this early
morning and coming to attend this talk as
well.
I'm going to talk about the attribution
revolution and why I think that we have
a possibility here of turning copywrite
upside down or inside out.
If you want just a quick
show of hands, just to give me an idea
how many of you have heard me talk
before?
Not so many. Excellent.
Then you're going to be surprised by this
one.
I'm going to show you an image
and I would like to have a quick show of
hands as well to see how many
of you in this room can recognize
where that image is from.
If you can identify the author of it
or perhaps identify the series, which is
from Show Hands, where
is this from?
OK, fairly
good.
I had a talk last week
in London at the Open Document
Foundation's meeting.
And where are you talking to people who
are used to writing word processors?
You can imagine that this joke went off
quite well with them.
OK, most of you recognize this.
This is a CD is drawn by
Randall Monroe.
He Randall has a peculiar style of
drawing, so it's quite easy to
recognize it whenever you see it.
He also has a sense of humor that
attracts many of us.
Now, let me show you another
one, though, and I'll ask you the same
question. Quick show of hands afterwards
to see if you recognize where this image
is from.
OK, one
oh, OK.
To you have seen this before.
OK, two people
recognize this one.
So the rest of you might be surprised
when you learn that this image is,
in fact, also by Randall Monroe.
It is also part of the
universe comic number seven in
the series.
Now, why I'm showing you this
is because knowing
that this image is part of
a CD, it probably
changes the way that we relate
to it. It changes the way we feel about
this.
Before we knew that this was drawn by
Randall Monroe, this was just an
anonymous sketch that I could have taken
from my own sketchbook or found anywhere
on the Internet.
But once we learn that this is by
Randall Monroe is part of the CD
universe, that suddenly
we have the context that
makes this image valuable
to us. It gives us some meaning.
And I can almost guarantee you that
if we tried to sell this one,
if Randall would sell the original
of this, you would obviously get a lot
more money as well if
that knowledge was conveyed to the
potential buyer.
So knowing
where things come from.
Knowing who created something, who's the
author, when it was
created, where it was created,
now all of those things are quite
relevant and we see them all around us.
We see them in Wikipedia.
Citation needed.
We see them in science.
Right.
Obviously, everything that we've done
and for as long as we can remember in
terms of scientific advances builds
upon what people have done before.
And we were used to crediting those
people by attributing them
when we write our papers or journals
in politics.
Well, know you can claim that
in politics is maybe not too common
to attribute to some known
source that people can actually check.
But as a politician,
you do this all the time anyway.
You attribute your statement to somewhere
you attribute to farce from somewhere
in culture, in art.
We have this. We attribute we build upon
something from before in food.
Well, OK, I admit this is a bit
of a stretch, but if you take
up food cotton, one of the first
things I do is I usually flip
it around. I look at the list of
ingredients.
Now that's, you know, that's attribution
and it tells you what does this actually
contain? Where does it come from?
What made into making this product?
And this is the provenance
of a work.
This is the history of something.
This is where something has been before,
where it was created, who
created it, when it was created,
for what purpose was created and
then what has happened with it.
Until we see today,
if you walk into a gallery and you look
at paintings on the walls.
You're most likely going to be interested
in the information about
those paintings as well.
You're not just going to look at
paintings, you're going to look at the
provenance of those paintings.
You're going to look at who actually
painted them when they were painted,
perhaps why they were painted.
The title of it can give you some
information, can use some knowledge.
It gives the paintings some meaning
now.
Provenance.
Is also connected to the aspect
of reputation,
reputation, obviously be, you know,
something that we all have around
us today as well.
If you look at LinkedIn, Facebook,
Twitter, everything is about building our
reputation.
Go on GitHub.
You're talking about reputation.
Your every contribution that you make
contributes to your reputation, your
standing in society.
And that's facilitated by
the attribution is facilitated by people
knowing what you have actually created
is knowing what
you have contributed to cyto.
Now, let me ask you
one more thing so quick, so
has this world see who is the avid reader
in this room?
If I say Woofy
show hands, how many knows what a goofy
is?
OK, I'm going to send you to the library
straight after this over
here is a reputation
based currency that was first
envisioned in down and out in the Magic
Kingdom by Cory Doctorow.
Now, in this story, down
and out in the Magic Kingdom, Cory
Doctorow hypothesizes about
a potential future in which
the currency that we had today is
replaced by reputation.
What do you do? And what you create
contributes to your woofy, which you
can do in exchange for other things in
turn.
Now, when Cory doctor of wrote
this,
this all obviously seemed quite a lot
like science fiction and it's written a
science fiction is Cory Doctorow after
all.
I would argue, however, that it's
actually not science fiction.
We actually have a reputation based
currency today as well,
maybe not exactly in the larger
scale that Cory Doctorow envisioned,
but we do have it nonetheless.
And this morning I was reminded of one
example of it, and I took the liberty of
slotting that in here.
How many noble advocates?
Not so many as well. So I'm going to
introduce that to you as well.
OK, this idea, advocates, not
orga advocates, is one of
the earliest, very earliest
attempts at creating
essentially a social network.
It pioneered the concept
of blogging on the Internet,
sharing your experience with other
people, and it developed a system
of trust.
It took the web of trust and implemented
it in its own system so you could certify
other people according to their
experience in this case, within the free
software community.
Now, it was founded in 1999.
So that's quite a while ago.
Right.
And it's been quite frequently cited
since because it really was one
of the first to try to do anything
similar to this.
Now, as you can see, I was
on Adubato already in 1999.
Now, that gives you a hint about how old
I am. But it also gives you an
understanding of how long I've been
working with this now.
Is that important?
Well, to some extent, you know, it's not
really. Um, but if I look
at other people that are on advocator
did this morning because I was curious.
You got Bruce parents
joined in early 2000.
Richard Stallman joined in mid 2000.
Bradley Kuhn joined in early 2001.
And then you got me joining in 1999.
And of course, that's then part
of the story. I was before everyone else.
Right.
Do I feel proud about that?
Well, you know, I'm human, so of course,
I feel proud about that.
I was an advocate for all these
are big shots.
Doesn't mean anything.
Not really.
But it's part of the reputation
mechanism.
And I'll introduce to you another
product as well, which came
to my attention until fairly recently.
So, again, see how
many of you know about this project
as P2P value,
how many recognize P2P value.
OK, one person, Chris,
is not here. Is he here?
OK.
Peer to peer value is an European Union
funded project, so it means that
is huge research portion within
this project.
But what I find interesting when I look
at this project and I look at what
they're promising to deliver or at least
what their objectives are,
I highlighted two things here that's
coming up.
They want to deploy a federated
platform in which real
world communities will interact,
participate and collaboratively
create content to the Commons
based peer production school.
And they want to develop a set of value
metrics and reward mechanisms
that incentivize the participation
of citizens and so-called commerce based
peer production. Now, to me,
that's a reputation based economy.
That's the budding stages of
taking what we have on
LinkedIn, on Twitter, everywhere
else where we're talking about reputation
and trying to put it in a larger
context, trying to create some platform
that can actually facilitate this,
not only in the sort of reputation
because I'm publishing something, but
in terms of reputation, because I'm
creating something.
When I started thinking about
attribution, I started thinking about the
attribution revolution.
I started talking to people and I started
talking to photographers primarily
because I saw them obviously carrying
quite a bit about being attributed for
the photographs that they take.
And if you look around at newspapers,
you see pretty much all the photographs
are attributed to Getty Images, AFP
or some other agency.
And you might even have the name of the
photographer there.
Now, something that I realized
when talking to people was that everyone
seems to agree that attribution is
important and was talking to some
friends of mine who are photographers.
They keep telling me that, you
know, I know the direction
in which the world is turning.
I see the way the people are taking my
photographs. They're sharing them online.
They're publishing them on Twitter, on
Facebook.
And I'm OK with that because I know
that I can't actually change the course
of history and I can't change the way the
people behave.
But if we can make sure
that whenever my photographs get
published, I at least get attributed.
That would solve a lot of concerns
that people have, unfortunately,
we're rather bad when it comes
to actually giving credit where credit
is due to actually attribute photographs
when we do use them.
Now, Creative Commons licensing as one
example, they stipulate that
whenever you reuse a work, you must
attribute it in a manner reasonable
for the medium of publishing it.
Still, we see a large
part of the commons which is not
attributed when it gets shared.
So two years ago, I
started working on a project called
Commons Machinery, which is
an organization that aims
to make attribution information,
metadata about creative works, visible
and actionable, now
visible.
Means that we should actually be able to
see the meta data
that are connected to the works that
we're sharing.
Unfortunately, that's not always true.
And of course, a bunch of issues along
the way in the early 2000s
when at least the Swedish government and
I'm sure other governments as well,
started publishing like court proceedings
and similar documents online,
usually did it as word documents.
And when it tried to hide someone's name,
they would just take the marker in in
Microsoft Word and strike something out
of black. And obviously, people figured
out that you can just open Disneyesque
control said a few times and undo that.
And then you got a name right.
If you put it as PDF,
it might look OK.
But if you look underneath everything,
you know, you still have the text and you
still have a block of black above it
and you just need to separate the two.
And then you have the name, which means
that today people are so afraid of
publishing anything detailed that most of
the time they print something
physically market and then scan it again,
which is obviously ridiculous because you
lose a lot of information in doing that.
But they do that for one particular
reason because they don't know.
It's not obvious to them what information
is conveyed when they're publishing
something, when they're sending their
files around.
They cannot trust that what they see on
the screen is the only thing that is
available there, even if they take
painstaking effort to remove
all the names completely, you know,
clear away the history of the document,
it's very easy to just leave out
the fact that you can just go to file
properties and you maybe have some names
in the title or the description of that
document.
So with machinery, we wanted to make
the metadata visible so
that people actually are aware of the
meta data that gets passed around.
They are aware of the information that
their documents and files contain.
Obviously, there's a privacy issue in
that as well to make that visible.
But then the other part is to make it
actionable and by actionable,
it means that we need to have a
way to actually develop
our software so that it can
act upon that metadata
to give us helpful advice and to give us
helpful information about the
works that we're using
to allow, as an example, a word
processor. When you're inserting an image
to automatically tell you that this image
is from this particular author.
Would you like me to put an automatic
attribution to that author in there?
That would be helpful, but we can only do
that if we have actionable metadata.
So fortunately, we are
funded by the Shuttleworth Foundation
for a period of two years, which is now
just coming to close.
Because they were interested, as I was,
to see what would happen
if we practically start putting our ideas
in practice, what would happen
if we start implementing systems
that supported retention
of metadata for digital works?
Where would that lead us and where would
the problems occur along the way?
And we've learned a lot since he started
working on this.
So for the remainder
of this presentation, I'm going to
take one small step back and
I'm going to talk a little bit about a
retrospective to talk about where we came
from and what we did in the process.
Up to now, I'm going to mention where
we are now, what we need to do next.
And then I'm going to come back at the
end to talk about what does
that actually mean for copyright?
Because you remember that as part of the
title to any copyright upside down.
And I hope that I will live up to that
promise.
This is an image
from one of the first white papers we
produced.
Now, this shows you
the different standards that are
available to convey
information about works.
So these are all metadata standards,
different levels.
It can be difficult to read from the
back. But we've got EXIF standard,
which is a meta data representation, but
it also is information about
the work itself, like the author and the
license that fits in there.
IPC is a similar standard like EXIF,
but it's created by the International
Press and Telecommunications Council
specifically for images we got.
S&P was coming out of Adobe
as well, doubling core
odiously specifies the licenses
problem, which is provenance
standard and all these other standards.
Is actually a bunch more.
You'd be surprised what you find when you
start looking at this.
It seems that everyone has been thinking
about this at any point in the past, has
decided that whatever standards
are available are not suitable for them.
So we figured out quite
quickly that there are simply too many
standards.
There's no way that we can make this work
if we have, you know, even
five percent of the works using excessive
standard to describe themselves, five
percent using AP, DC, five percent using
five percent using something else,
there's going to be a nightmare to
actually try to implement that.
And each of them don't really see enough
use either.
Even EXIF, which is probably the most use
standard for images to convey
information, it doesn't
really have enough use.
It has no tool support to a very large
extent.
Load something into a photo editor,
change it round and save it.
And that information is very often just
lost because the tools don't actually
support retention of metadata
or passing it along.
There's an embedded metadata manifesto
that came out or the international press
and telecommunication councils.
They did a study of social
media platforms and
it was fairly easy. I mean, you just took
an image with EXIF and IPTV metadata
embedded within that image.
They uploaded it to social media platform
and then downloaded it again and they saw
what happened to the metadata.
And lo and behold, in almost
80 percent of the cases, the metadata was
just lost.
Thika,
500 pics, Twitter,
Facebook, probably one of the worst of
them.
They just ignored metadata.
They took it away.
Google was one of the better ones.
They actually took some effort to retain
at least EXIF and BTC information,
but some of the other information was
still lost as well.
So.
Retaining metadata by hoping
that whatever you embed within the file
will get retained.
It's not going to happen.
It's a panacea at best.
So we're sort of thinking about what
other ways are people using
creative works.
And we came up with a case of copy paste,
which is the very simple procedure of
someone finding an image online that they
like clicking copy on it and then
going to, you know, like a presentation
editor and clicking paste.
And we're sort of thinking about how can
we make the metadata
of that image information that
we need in order to attribute accurately
be carried over in that operation.
And now I'm going to slide into slightly
technicalities of how we did that,
but I hope you'll follow along anyway.
It's not too technical indeed.
So the first thing we did was
we simply split
the clipboard in two, essentially
on the clipboard by default.
If you copy an image, you might place an
image JPEG resource
available for the recipient application.
And it just looks and say, oh, here's an
image, grab that one.
What we did when someone clicked copy
was that we put not only the
JPEG image on the clipboard, but we also
put an RDF fragment
containing the meta data as a machine
readable meter reader.
And then it would up to would be up to to
receive the application.
Once I click paste to say,
you know, I can get either the image
of self, I can get a meta data or I'll
get both.
So that was a first attempt.
Later, we changed that completely
again, we
realize that a bunch of issues for this,
I'll get back to them.
And in our more recent.
Prototypes that were built, we instead
of putting the image on the clipboard, we
actually put an HTML fragment on
the clipboard, which has RDF
metadata embedded within it.
So you can see, for instance, the title
here and the license together
with the image and the source of it.
Now, we implemented
this hour variations of this and
quite a few tools.
And Gady Teekay, Jim Inkscape,
Lee Ralph is a little higher ed media
goblin and I'm quite proud of and I'm
quite happy that we were able to
bring this sort of copy paste
scenario to a close to the point
where we could find an image online.
We could find it on Flickr with click
copy of it, would get it into
LibreOffice, would kick paste and will
insert the image together with the
attribution. And then if you copy again
from there and get it into a Web based
locator and could paste the attribution
carries with it as well.
Now the problem we had when implementing
all of this is that in most cases,
whenever you're talking about copy paste,
that's an operation.
It involves changing the core of the
applications.
It's not possible to do this in the
general case with Yuson additions or an
extension to a program.
You need to actually change the core.
Or alternatively, you need to implement
your own copy and paste functions,
but obviously very quickly gets messy.
You also have the UI visibility issue.
End of most applications don't really
show the metadata.
They don't care about it, so they hide it
away. And as well, we realize
that there are significant clipboard
differences. What worked for us on an
X based Linux system
did not work on Windows and did not work
on Mac OS X, so we were kind
of stuck in that path.
So that's why we went back and we did the
e-mail approach as well, because that
works on all platforms.
So we did a copy paste,
we even got to the point where we
got LibreOffice Press Center
to accept images that repace it
into it, and you could paste as many as
you want and you can move them around.
You could remove them or add new images.
And then at the end of the presentation,
you would ask you to insert new slide and
then insert credits.
And it will give you a list of all the
images that you used in your
presentation.
All of that code is up on our GitHub, so
please feel free to check that out
if you want.
Now, doing this, however,
is a very massive effort
because it involves changing every single
application that we use.
And that's quite a few and
it becomes very application specific
whenever you want to do something for
LibreOffice, it was different than doing
it from a lower ed, even if you can
abstract parts of it away and make use
of some common libraries,
it was still quite a substantial
effort to actually get this working at
all.
So we're sort of thinking what would be
the Unix way of doing this?
So if the problem is to retain
and manage metadata,
why don't we solve that particular
problem? Let us not solve the
issue of making this work
in an application, but let's solve the
simple problem of retaining and managing
metadata.
So we started working on what became
known as a logio.
Elijo is a distributed
catalog of creative works that's a
glorified term, what we're
really talking about, honestly, is
a meta data database.
It's a database that is specifically
crafted to hold information
about creative works.
And it can look like this.
You'll get the.
The identifier at work, which in this
case points to our catalog and the
identifier of it, and you will get a
Jassam structure in this case back,
which gives you a locator, for instance,
saying that this image is while in this
case Alexanderplatz in Berlin.
It has a block cache, which I'll show in
a little bit, and it has a particular
license. In this case, it's not a
license. In itself, it's just a public
domain. Mark now
Eulogio uses W three C media
annotations as its way of recording
information about works, which,
you know, it's a fair enough metadata
standard that most other metadata
standards can be mapped into, like
EXIF and Ibtissam and provides
an API.
So for any image that is part
of this catalog, you can easily look it
up using the jewel of that image.
Or if it's an image indeed, then
the block hash of that image.
And I'll explain Bloxwich in a while.
The way it works is that you have a work
record which explains the
image itself, gives you the author, gives
it license, and then you have multiple
media records, because we realized quite
quickly as well that if someone
takes an image posted to their own
website, it will most likely get a
different URL.
So it will be the same work but will
have a different media.
It might have a different resolution,
might have been changed in some way.
So you can have multiple mediums
connected to each creative work.
And we've seen in the database
with 22 million images from Wikimedia
Commons.
So essentially for any image that as part
of the Wikimedia Commons, you can look
that up in our database and we'll get you
back to metadata.
We also developed to browser plugins,
one for Chrome, one for Firefox that
can interact with this API
and you're asking yourself, so what does
it really do?
Well, this is one of the things it does.
If you're out browsing the Web, you
got a logic plug in installing Chrome or
Firefox.
If you see an image or define
interesting, you can open the allowed
your sidebar and you identify
the emerging query.
And if that image is part in this case
of a logo, meaning by extension, that is
part of the comments at a moment, then
it will get you the information about
that image. It will show you the title of
it, who authored it
and give you the
appropriate license for it.
If that is not an.
It will even Greenmarket
licenses that are free cultural licenses
because we love them.
Now, it also offers you the opportunity
to copy this image as an e-mail fragment,
and you can take that image and paste
it into LibreOffice as an example,
and it will copy over
not only the image, but also the
attribution and at work straight
off without anything except a browser
plugin, which is nice.
Now, what's the catch
of this? Well, there's obviously a catch
to this, which is that.
Identifying an image
that has been resized as an example.
How we can do that depends heavily
on the algorithm that we used to do
that matching, and
for Lajo, we wanted to have an algorithm
that was very lightweight, that didn't
take a lot of resources that.
Could be calculated quickly within the
browser, and that would generate
some kind of value for an image
that would not change even if you
resize the image
and ideally it should generate as
few as possible false positives
or false negatives.
So the way that our algorithm works now
run you through the algorithm as quickly.
So did you see it before
I talk about where it does not work?
So this Alexanderplatz, this Alexandrov
person, seventeen hundreds in Berlin
and you'll see that I've taken this image
and we've split it into 16 by
16 cells.
So it's a matrix here, 16
by 16 happens to be 256.
So that's a number of bits that are
hashes actually generate
what we do with this image after we
segmented it into this way, into this
matrix, is that for each
cell we calculate the
sum of all the pixels within the
cell, and we do that for all of the
cells. So we'll get something looking
like this, a bunch of numbers across the
board.
We calculate the median
of all those numbers and then
we go through each cell in turn and
we see is the value
within that cell above or below
the median.
And then we assign either a zero or a one
to that one.
So then we get to a hash looking like
that, and then we just wrap that up and
pack it as a hexadecimal number.
And that's our hash.
OK. So it's very simple.
It's very efficient.
Takes almost no time to compute.
And you end up with hashes looking like
this. So the first one is a hash
that I made of Alexanderplatz in a six
hundred forty eight times three hundred
twenty six pixel resolution.
And the second one is the same image
but rescale to two hundred by one hundred
and two pixels.
So about one third the size.
And you'll see that they do indeed look
similar.
They're not identical
because obviously some things might
change when you rescaling the JPEG.
They're not identical, but they don't
differ that much either.
They differ. If you expand this into the
bit feel that we have, they differ
in six positions.
So six bits are the difference
between this larger
size and a smaller size.
So when we apply the block hash algorithm
and we come from experience
to say that if something is
six bits or lower or ten bits
or lower, then we can be fairly
confident that we're talking about the
same image, even if it has been resized.
Unfortunately, however, reality
comes and bites you in the ass.
So this is
my son, this in Greece a few days ago,
and it represents something that
people love doing.
And they take pictures in this case, our
kids, they take pictures of
Skyline's.
And all those pictures have a common
denominator that they have a very
bright upper half, usually
white or blue sky, and then they have
a very dark contrasting
lower part.
And what happens if you have a very
bright part on top and a very dark
part of the bottom?
Well, what happens when you do the
numbers? You end up with an upper half
being with very low numbers and the
lower half being with very high numbers.
And if you take the median, it will be
somewhere in the middle of this.
But when you then check if something is
higher or lower than the median, you end
up with the hash that essentially
a bunch of zeros followed by a bunch
of ones because the contrast is so
great between upper half and the lower
half that all the differences
within those regions are simply lost.
Their overpowered by this.
So this was the original block
hash algorithm, the way it worked when it
was implemented in straight off from the
research literature.
We changed this algorithm and we changed
it in a very easy way.
We simply split it up,
split this field up into four
distinct horizontal blocks.
And we do the median calculation
not for the entire image, but for each
block itself, which means that
even if the first block is only blue sky,
even a blue sky will have slight
variations in it.
And if we calculate the median on that
and then due to the calculation,
then we'll get a lot more contrast
or got a lot more details of it.
So that's the way the algorithm works
right now and gives us hashes like that.
So it gives us much more detail
for essentially the same images.
Now we're still.
Getting collisions, that's unavoidable,
we're getting collisions in about one
percent of cases, we
got about 100000 images from the
Internet. We ran our
our algorithm on them and we compared
them to each other in a crosswise manner.
So there's one percent collisions.
Collision here means that two images
or even more images generate the same
hash, identical hash.
Now, however, in 84 percent
of those collisions, we are talking
about two to three images generating
the same. So we figured that this
is fairly OK.
This is also one hundred thousand random
images, which means that
ClipArt maps and
various other things, which maybe differ
in very small details.
They're also counted as a collision here.
We also get a number of false positives.
However, these are.
Images that are recognized as being
similar without actually being similar,
because the algorithm generates close
matches for them, if we set the
maximum distance and allow up to
10 bits variation between two images
to classify them as the same.
Then we get about one point eight percent
false positives.
We can get that down quite substantially
by us lowering the distance that we
allow. If you say three or
five, we're down to less than zero point
two percent. So
somewhere there, we feel that we're
doing quite well.
Now, what about derivative works?
What about ClipArt?
Well, in one word, forget it.
Derivative work, meaning when you take an
image, you add a border to it as an
example. You take an image, you
crop it in some way.
Now, if you can imagine the algorithm,
you'll quickly recognize that if you drop
an image, it will generate a very
different hash from it.
So we set the bar and we set
the limit for ourselves, saying
that we will do
our best to match
verbatim copies of what work you
can resize it as much as you want.
You can change the format from A to
JPEG to give them back again if you want,
and we'll do our best to match that.
But if you make a derivative work, if you
add a border or you try to change around
an image in some way, then
all bets are off.
We're not going to guarantee you a match
on that one as well as ClipArt
or any other diagrams or
graphs where you have large areas
of white or black or some other color and
a few lines.
It will do a generally a rather bad job
at that as well, because, again, you have
this high contrast areas,
but instead we do get something that's
blindingly fast and we're very small
hashas with few false positives.
And this all up on blockhouse, on IO, if
you feel like implementing this yourself,
we have a look at what it does in
practice.
Now, unfortunately
for our case, 22 million
images is not nearly
as much as we need to actually make this
useful.
Now, 22 million images may sound like
a lot, but it's a very small
fraction of what we actually need now.
Creative Commons.
But a month ago released their
sort of state seat
of the year and saying that about 800
million images, 800
million works out there, which are
openly licensed.
That's the size of the Commons at the
moment.
Now, not all of those are images, but
a fair portion of them are.
I'm estimating that there's probably
about a half a billion images out there
that are openly licensed.
That should be part of a larger but which
is not there today.
Now scaling up to half
a billion images, it's doable
in terms of databases.
Doesn't add as much as we would fear.
So we can easily do that.
However, we're talking about
searching by a perceptual hasher.
We're talking about searching for
a hash value, an image where we allow
up to 10 bits of difference.
Now, if we say that, we're not
going to allow any difference.
That would be a very easy search.
We can do any kind of database,
can search for unique values.
That's not a problem.
But if you're searching for something
that is similar to something else,
that becomes a very different problem.
So we found,
again, some research to help us along our
way.
This algorithm, surprisingly not perhaps
comes from Google.
It's called Items Search,
and it partitions
the hashes in a way
that you avoid doing a
search of all 22 million
for any hash you throw at this algorithm,
it will give you back maybe a few
thousands of possible matches.
And then you need to sift through those
to figure out which are real matches and
which are not.
Again, also available on GitHub
in search of IoE.
Now, where are we going from here?
Well, the first thing we want to do
beyond scaling to half a billion
works, which we should do, is
to flip the reed right bit.
Because at the moment, while logic
and while the API has provisions
that makes it possible or would make
it possible for someone to edit
information that's all within a LAJO,
we haven't actually enabled that yet.
So far we have just taken information
from Wikimedia Commons and put
that into the database and sort of read
Only Repository.
And we rely on people updating
information on Wikimedia Commons and then
we get that information into a larger.
But flipping that bit and making it read
right, that's what's going to change
things.
We also need to extend a larger to
support non images so any other kind of
creative works. Again, scales quite
massively beyond a half billion even.
And we want to implement support for the
API directly in applications.
So, again, going back to the application
side and figuring out, OK, now
that we have solved retention and
editing or meta data separately, how can
we then make a link to the application?
Now.
How the heck does this relate to
copyright, as I promised from the
beginning?
Well, it's easy to think
of a logo as a copyright registry,
and I promise you that it is not
a copyright registry is
something that I personally detest.
A copyright registry is an attempt by
someone to
provide an authoritative database
and authoritative information about
who owns certain creative
works.
LIGO is not an authoritative source
of information, and logic is not a
copyright registry, Eladio
is billed as a community curated
repository.
In this case, the Wikipedia community to
start with, with an
implicit agreement or respect.
So this is something that we learn from
Wikimedia as well, that there's a reason
that people keep contributing information
to Wikipedia. There's a reason why people
take painstaking efforts to
actually keep the meta data on Wikimedia
Commons up to date
and reliable.
And that's because there's an implicit
agreement that we actually want to
respect the author.
We want to respect
the author enough to give accurate credit
where credit is due.
We don't want to lose that.
Now.
Joe.
In this way takes a slight
side step away from
an initiative like Creative Commons.
Now, obviously, Creative Commons is the
licenses themselves and Creative
Commons was an attempt to work within
existing copyright regime to show that
given the situation at a time in 2001,
we have copyright you want to share.
We can work within this system
to give you the tools, the legal
tools that enables you to do that.
I believe that we are coming
to the end of copyright
as we know it right now.
Quite recent phrase within the software
community has been POS was
posted open source Sweida,
where the guiding
light is essentially the phrase
fuck licensors put it on GitHub
and.
Yeah.
And I think we're seeing the same in the
criticism as well.
Copyright is losing its importance
day today.
And we're coming to a place
in time where,
you know, within five, 10 years,
I'm very sure that the European
Parliament and other parliaments around
the world will take steps to make
additional exceptions to copyright
as it is today, to allow even more
private use as an example
without hindering people in
their day to day activities.
So copyright is changing
and a logo is one of the tools that we
need along the way because the logo
is post copyright licensing, it doesn't
really care about the license itself.
It obviously implements support for the
free media annotation standard.
It gives you the tools that you need if
you want to record information
about a license.
But the license is not terribly
important.
The important part here is who
actually created it was the provenance of
a particular work, was the details about
that work.
Meaning that from your side,
we take very great care to respect the
author, but not the institutional
copyright, because just as
the friends photographers that I'm
talking about before yesterday saying,
as long as we make sure
to attribute accurately.
We're good so we can
take control of the provenance
of creative works by using tools
like a Elijo doesn't need to be allowed
to be tools like it.
And we can show the world that we
care about authors.
We just don't care about copyright.
But we care enough about authors to
take as a collective effort
control over that information,
to control the provenance, to keep
a record of where
creative works come from, what happens
to them, and make sure that we attribute
the author's value.
It's my firm belief that
if we respect
authors, if we attribute
the authors, if they record
their contributions, and if we're honest
about all this, it will make it easier
to contribute to the Commons.
It'll be much easier for someone to say,
here is my image.
I'm going to upload it here.
Do what you want with it, just make sure
that I get credit for it.
If we respect, attribute and
record information about images
that will help raise the value and
meaning of digital works, just as I
showed you in the beginning, just
as knowing that
the sketch I showed was by Randall Monroe
changed a value and changed the meaning
of that work for you, it will
change the value and meaning of other
works as well.
And if we do this as a community,
then copyright holders
will eventually be devoid of
their currently exclusive
right to dictate, because that's
what we're doing with copyright
registries.
They're telling us that we are
the owners or they are the owners of
the culture that we have around
us with tools like Lajo.
We're coming together as a community and
saying that.
We know who authored this,
and we will take care to recognize that
you don't need to tell us, we'll keep
track of that ourselves.
Thank you very much.
And thank you for listening.
Thank you, Eunice.
So we have 15 more minutes
for questions.
Do we have any so
microphone four and then we have one
online as well.
Hello, thank you very much for your
talk. I'm very interested in this
function, but I don't see how this
function in desktop applications
is still useful.
I cannot use a LibreOffice
plug in. I need something in
WordPress. Com. I need it and I need
it in Facebook.
Have you talked to these platforms?
Yeah, OK, you're right.
And that's what I handed at the beginning
as well, that in order to make this truly
useful, we really need to
support us while we need support for this
in the applications that people use day
to day. And that was one of the reasons
why we decided to change our approach
to passing information on the clipboard
by passing information on the clipboard
as an HTML fragment.
We've actually shown that this works
in LibreOffice, it works in WordPress,
it works in Microsoft Office
as well. It works on a
whole range of tools by
default because most of the tools today
can handle e-mail right now.
That's not the whole story, though,
because in order to actually make use of
the meter reader that gets passed along
and to do something intelligible with it,
then again, you do need application
support. So we've started to have those
discussions. We started talking with the
libraries community as one example,
and they are catching up.
But unfortunately, the
the awareness of metadata, Sanders
awareness of what could be possible
is a little bit lacking today.
So it will take quite a long time until
we actually make something sensible out
of it.
OK, so the next question from the online
world, thank you.
There's one question.
Are there any plans to to make images
trackable after they have been cropped?
And have you looked into how YouTube
does it? Because there seems to be very
good in it.
Yes. And Google it as well.
Yes.
So we looked at a number
of different ways of doing
the calculation so that we could
potentially detect images which have
been cropped or changed in other ways
as well.
Unfortunately, from our perspective,
most of those algorithms that are
available are either kept secret
or they're patented, which means that
implementing this and free and open
source software is a no go zone.
It will get better.
There are research underway to make
this possible and we're continuously
looking at changing the algorithms,
updating it according to what we learn.
But it's quite far from
having something that would detect a
derivative work as well.
OK, thank you.
Microphone number two,
hello, thank you for your work on your
underfunded site and the workflow side
of things. I have a question about you
talked about distributed database and
communicate curated
direction, but now the focus seems to be
on very specific projects and very
things.
So what could be scalable things
to to work on, to get more sources
involved or to create those kinds of
kinds of things?
And would you be open to other
contributors like, I don't know,
libraries, archives,
European projects,
whatever you can think of.
So what would be the long game in
kind of distributing and community
creating for.
So there's two communities are two groups
of repositories that we're talking to
to get their information as well.
Within a larger one is Europeana,
which obviously captures a lot of the
galleries, libraries, archives and
museums around Europe.
That would be one.
They are safe, creative, which is in
fact, you know, part
Kopra registry to get their
information within LIGO as well.
But still, you know, at that point, we're
only talking about specific collections.
We're talking about read-only
information.
So the logical next step is
indeed to flip, to read roadbed, to make
it editable, but to think through
because we're honest and not quite sure
how that would look like.
Because how do you deal with potential
conflicts when people keep editing the
same information?
So we'll need to go again to see
what Wikipedia is doing in this, you
know, see what policies they have in
place and how that works and see if
we can replicate that on our side.
And in terms of scaling beyond this, in
terms of distributing this, we
made very sure from the beginning that
the identifier that we have
for individual works within
the larger catalog is a URL,
which means that anyone can essentially
set up a catalog and have their own URL
scheme for that catalog as
long as they don't change the API.
If you have the URL, it doesn't matter in
which catalog you actually look up the
information, you'll get it anyway.
Microphone number four, yeah,
there's one comment on the
euro that
we probably want something which
can survive like 100,
200 years,
and whether that's going
to be solved
by using euro as we
have today,
might create some problems.
I was also interested about this on
if all this can be applied to
not just pictures, but books,
music, whatever.
And then there was
one technical comment.
The all
functions should be one pass
because if you go otherwise, you will
go to the RAM so
twice.
So that was the technical part
of the comment.
OK, I see if I
can remember those three things.
OK, so on that bit, yes.
We were quite a lot with the specific
algorithm during this.
And now that we feel that we settled on,
you know, the way it works best in our
environment, we've
documented this as well as NFC, which
was submitted to research the namespace
for it. And then it has a very specific
definition which makes sure that, you
know, if you want to call something like
hash, then you need to follow this
particular specification
now.
OK, I'm sorry.
Could you go back to the first question,
one from the other point?
Yes. The Euro.
Thank you. Um, yes.
I skip over a very important piece when I
say that everything will be solved by
euro,
because as I said in the talk as well,
from the beginning, we know that
any kind of metadata gets stripped very
easily from a work.
And even if we say that, you know, all
we need is a URL, all we need is an
identifier, which is a URL
that's going to be stripped as.
So that's not the
final solution to anything.
We need to to work on different
approaches of identifying works.
Um, the only thing I was saying there is
that at least with the URL,
we can make sure that this could
potentially be distributed across
different catalogs and not just be one
single monolith.
OK, and the second point
was.
Oh.
I think I think
probably the survivability.
I remember correctly.
Although, yes, lighter works.
Yes, thank you. You're applying to other
non images, right?
OK.
One of the reasons why there are so many
meta data standards is that there
are so many different kinds of works.
What is relevant for images
in terms of metadata is not relevant
for classical music.
As an example, what is relevant for
classical music in terms of
authoress and who plays what instruments
and what instruments are available is not
relevant for pop music.
So that's reason why all these standards
have come up already is one of the
reasons.
And we believe that
using media annotations allow
us to cover different sorts of works,
but it really need to be thought
through a bit more before we start
working with it actively to figure out
what information is actually important
to convey about different kinds of works
and what they would
do, the meta data centers looks like for
those kind of works.
So that's a larger piece of work.
So there's one question from the
Internet. Yes, thank you.
Why don't you work with data from other
sources like Flickr that also provides
good metadata, contains a lot of free
work and info about the author?
Yeah, we are.
In fact, we don't
have the place yet. We have spoken to
Flickr.
We have a communication going to figure
out how
we can get that information, how we can
integrate it in our system
depending on how things go.
I'm quite confident, though, that we'll
be able to integrate that and to make it
available through the same API.
Unfortunately or fortunately for
for us, Flickr is a huge
resources, but 300 more than 300
million images, which means that
even if we took, you know,
took a year to do that, we're still
talking about incorporating about a
million words per day.
At a moment, we can do about six
million words per day, adding to our
database, which is a fairly large number.
We can probably scale a little bit beyond
that. But still, we're talking about a
number of months works when we actually
start working on that.
So one more question,
there are additional one from the
Internet.
If you have questions, I'll be available
up here for a little bit more after this
talk. We also have some information about
Comus machinery and the work that we've
done, which will be available down here
from Lainer.
And I will have it up here as well.
So feel free to Chrebet.
OK, thank you, your honor.
Thank you very much for the kind of
applause.