[Music]
hello everyone and welcome back from
lunch hopefully the catering was as
awesome as the catering was here
um i would like to introduce simon uh
simon will be discussing with us the
architecture and software that they
chose um in making their api public
simon is a creative technologist at acme
your museum of screen culture which is
in melbourne a software developer
maintainer at a new internationalist
magazine and an open source uh software
and hardware enthusiast uh he helped set
up the mod which is the museum of
discovery and hacker space in adelaide
so on to you simon thank you
thank you
um
i will set my screen sharing going
okay
so hi everybody uh first i'd like to
acknowledge the ghana people as the
traditional owners of the unseated lands
that i'm speaking from today uh always
was always would be aboriginal land
and for those who haven't been to acne
we meet your museum of screen culture in
federation square melbourne victoria
we usually have about 1.5 million
visitors a year and our new experience
the story of the moving image takes you
on an interactive journey of screen
culture in films video games tv and art
it's also free so you should all come
and visit
um last year i talked about how we built
the digital infrastructure and private
apis that power acme uh including how we
deploy about 400 raspberry pi's and dell
microcomputers uh and this year i'm back
to talk about the work that our team has
done releasing our first public api
uh you can see it in your browser at
api.acme.net.edu
[Music]
that's a lovely little screenshot up
here um so
how uh why did we build it um
we received public funding
at acme so we figured that the data that
we make should be public too
and what do i mean by the data we make
um well museum collections might include
uh works that are held on behalf of
communities whose intellectual property
is owned by the creators until it enters
the public domain
um and also scholarly
scholarly descriptive metadata about
those works that museums create
themselves so we're allowed to release
the descriptive metadata um but not the
works in most cases um
uh cxo seb chan uh describes this really
well so i'll just pop in a bit
from him so he
writes uh acme might hold a copy of mad
max but
owns no ip to release even when it
digitizes that copy because the
underlying work is still in copyright
however acme owns all of the ip around
what it says about mad max and can
release that without seeking additional
permissions
so other museums hold things whose
underlying ip is now in the public
domain because they are so old
this allows them to release the work
itself
acme's collection is very young
and doesn't have this option
we do have some works that were
produced as government films
and so they fall under the crown
copyright as well as other works that
are called orphan works because they
have no known copyright owner
uh there are a third set of works whose
creators have given us limited rights to
release on other platforms controlled
and administered by acme and these are
what are on our youtube channel
um another reason we wanted to build it
is for regular updates so our last
starter release was five years ago and
we'd really like to release more
frequently so nightly if possible
uh we wanted to build for accessibility
so when we build the public labels api
um
that one is what we're going to use so
that visitors can translate and read all
of the labels that appear at acme using
their own screen readers
and we also wanted to be able to create
more rich data links
so that we can match collections data
with other institutions so this might
include ids from other film collections
like the dff in germany or else data
sources like wikitata
and we also love experimentation so we
wanted to build applications that extend
and transform our data
and uh public api is super useful for
that
so uh before we built it we needed to
answer who we were really building it
for
um primarily we're building it for
researchers who might use a study
representation and demographics in our
data
we also thought we should build it for
technologists
and take that into account so envisage
them using it in hackathons and to build
visualizations
we also need it for internal use
so we've got three teams technical teams
at acme the audio visual team the
information technology team and also the
team that i belong to experience in
digital
and we've all got creative people in
there who love writing code so the
public api allows us to develop
applications with our collections data
without the fear of bringing down the
private museums api um because that
would suck
um and we also built it for you so we
would love to hear what you think of it
if there's anything we can improve and
most importantly what you build with it
um here are a couple of examples from
rmit students who used our 2016 metadata
so here they explore gender
representation uh on the left and also
the country of origin of works in our
collection on the right
they generated these images using the
metadata spreadsheet that we really
expect them
but with the public api these could now
be live and interactive
so this is a big dependency map of xos
that we built
last year that i presented last year at
the conference
and all of the applications it serves in
our museum and external facing websites
um don't worry if you can't read it it's
just to give you an idea of all the
things
so as you can see a lot depends on the
xos
uptime and performance
and hence the need for a public ati api
not to put any extra strain on it during
museum opening hours
um the private apis it exposes currently
uh the taps when people tap their lens
uh a lenses api for the lens itself for
constellations works creators playlists
monitor devices labels images and videos
so over time we'll release all these as
open apis
but first we wanted to focus on the
collection works api which is the one
i'm talking about now
so how do we build it
um
so we had xos which is our museum
operating system
and
that was really lovely and so what we
wanted to build
was
a glorified offline cache that was
serving json from the file system
um and so the public code repository of
the public api that we've released
includes the api server software itself
as well as the
collections metadata in both json and
tsv file formats
so most of the rights filtering is done
in xos and that inherits the logic from
our collections
cms which is called vernon
but some of the last minute tasks
or we had some last minute risk adverse
decisions by the organization which
meant we had to do a little bit more
rights filtering on the public api so
um
we've got some logic that we're going to
roll back into xos
after we've built the business decision
fields into vernon so it'll get cleaner
over time which is great
um but having the api code in the
metadata on the one repo
uh means that researchers can get clone
our repo and have all of the data ready
to go
plus it also isolates our private museum
apis completely from the public so that
they don't have any chance of
accidentally breaking things either
so what we used was alpine linux docker
container
the main reasons are it's small secure
fast
you can do repeatable builds and use the
same
image for development and production
which is really nice
in terms of the underlying software
the majority of our code acme is written
in python so the dream result was a
python based framework with minimal
dependencies that was quick and easy to
prototype and develop
so flask was really good choice for that
in terms of search we went with um
elastic cloud in production
uh and a matched elasticsearch docker
image for development so the same
re-indexing code runs on staging and
development which allows us for easy
updates and testing and bug fixing which
is great
in terms of the infrastructure
the acme ict team has a background with
microsoft
so we use terraform to build the
infrastructure on azure services
making use of horizontal auto scaling to
handle temporary load increases if the
api cpus average 70 or higher for a
significant amount of time
um
we're finding terraform pretty good
because it makes spinning up new servers
quite easy
though it adds quite a bit more tech
debt to our small team of two dabs
in terms of
nightly updates
to the api
um while building a separate repo for
the api updater i realized that a cron
job in the actual public api code repo
could do the same job so now cronjob
runs the same code which calls our xos
private works api uh it downloads the
json blobs
and saves them to the file system
and then we've got another little bit of
code that removes the image and videos
that we don't have rights to and once
it's finished it just checks for the git
changes
if it finds them then it pushes those
changes back to
the code the github repo
which triggers a github action to run
the linting and tests before deploying
the changes to staging on top of itself
which is quite cool so that's how
it updates the code repo by itself
um we have an environment variable for
toggling updates via terraform
um in a config map so this makes it
really easy to turn off any updates if
um without any code changes the api repo
just in case we have any problems
and we also have environment variables
for including images and videos so
over time as we've got all the rights
ready uh we'll add them to the public
api just via a
terraform toggle which is cool
um in production uh we trigger manual
releases uh weekly and this is done by
github
after we've done some data validation on
staging just to make sure we haven't
broken anything
and then we use unicorn server to serve
the json to you
in development
we provide an environment variable to
switch between the flask server while
building new features so you can do
hot reloading
and also the genocon server for testing
as well just if you want to test the
production
server on your laptop too
um so i thought i'd give a quick demo of
how all of that runs using docker
compose
so
um we pull a clone of the repo
we see the insert development folder and
then simply run docker composer
and that starts the api search container
with elasticsearch and also the api
itself so here it is running
um if we switch over to our browser and
head to port 8081
uh there you can see it
um so you can also go to works and see
an index page of all the 42 000
um
files there and you can also paste in
the id
and grab like a one object uh returned
and this is just showing that the the
search works locally as well so that's
elasticsearch returning the results
of a search too
so um what were the results um so
without any optimization to unicorn yet
um this is the speed that we got coming
back
for all of our requests so when they're
about three requests a second it's about
158 milliseconds going up to 18 requests
a second about
you know half a second so um that's
running pretty well for 100 a month
um and this is on the standard azure
d2v2 nodes
in terms of time to build this
the first commit we made just doing the
rough prototypes using flask was on the
5th of july
and then on the 23rd of september we had
our infrastructure running and
everything running in production which
was cool
so that gave us a lot of time to do the
final touches for the 11th of november
so about four months
um
in terms of dependencies and security um
because of the limited number of alpine
and python dependencies we don't pin
dependencies at all so they update
nightly with every build giving us a
pretty reasonable security posture which
is nice
um
and we've documented everything over at
acme dot ju
api so
hopefully the document is documentation
is easy to read but
um
have a go let me know if it needs any
updates or anything
um we've also got a blog post um with a
bit more history and some prototypes so
you can pop there at labs.acme.nb
um
and in terms of the prototypes um
because we found the majority of bugs
early in our testing
because we built the private apis
that was great but using the public api
ourselves for prototypes helped uncover
a few more which was really useful
so both the prototype applications we
built
run in jupyter notebooks which means
they can be run for free on google
collab online so you don't need to run
any of this code on your own computer if
you're
um ultra paranoid
or just usually paranoid
um so the first one we built was machine
dreaming
this one
generates images from our works metadata
so we thought it might be useful seeing
that we didn't actually release the
images and videos for launch
and the second one
matches wiki data biographies to
acme creators
so there so that's quite cool too
um then since we've released it we've
had some public use which is really
really nice um so paul from nfsa which
is the national film and sound archive
of australia uh he used the api to match
acme works to wikidata entities so um
we started matching craters he's
matching works now and it's really
really lovely
um
the other use was by aaron from san
francisco museum
he matched acme accession numbers to
website urls which is going to be really
handy for accessible accessibility
labels so he's working on a project so
that all museums can share this code um
which will read a museum label and take
you directly to the website which is
very cool
uh the other thing we learned about just
recently is that wikimedia australia
have launched a thousand dollar
fellowships um
and they're featuring the acme public
api as an example project
so
if you're into data you should
definitely apply for that
looks really fun
so um here you can see the first machine
dreaming prototype um that we created so
this is using the metadata from um the
matrix
and so
i don't know if you know i'll give you a
little bit of history about gans so gans
are machine learning models that pit one
network that generates the output
against another that classifies that
output
so they're used a lot in generative
music texts and images
and vqgan plus clip which is
what we're using here
that combines
machine learning models that generate
the image from text
so that's we use that to
pass the acme metadata in this case
it's split
so we pass in the title first and then
the um brief description
uh all split by a maximum number of
characters which it can handle uh and it
generates that image
so
as you probably know machine learning
models carry the biases which they're
trained on and so it looks likely that
there's probably a matrix poster in the
training data that we use given how
similarly that looks
um
likewise the strength image from our mad
max metadata
um it looks like there might have been
some film stills in the training data as
well given how accurate
uh that looks to some of the characters
in there
and so it's showing like every frame is
one more step um
that it thinks
uh is closer to the image that it's
dreamt up based on that metadata so
there's about 200 steps per
um
in our example that we used
uh here we fed the video game of the
hobbit
um but clearly the training data had an
image of the book in there so
um it kind of dropped up the book rather
than a video
game which is not surprising saying it's
a
spectrum
game so yeah
um
the last one here um the training set
also appears to know that outback
australia is aboriginal land too which
is very nice so if you'd like to try
some others as i mentioned our notebooks
run for free on google collab servers
and there's a link to it in our acme git
lab
um from the blog post api documentation
and also all of these links in the
slides work so
you can download them after my talk
so in terms of challenges
um so we wanted to release everything as
creative commons zero licenses
but yeah we couldn't for many reasons
um
seb chan uh the ct cxo uh has some
really nice words about this so he
writes uh this is not hard because of
technical reasons but because of
copyright laws ethical consideration of
creators rats outside of copyright laws
such as indigenous ip so should
indigenous works ever enter the public
domain
and other also other moral rights
acme and no museum has
resources to manually research
contact clear and re-license every work
in its collection for all purposes
so some works we have in our collection
even need us to contact the creator or
their estate to show in an exhibition
other works were acquired before the web
existed and thus don't have flexibility
without re-contacting the rights holder
so we had to remo remove a large portion
of our collection from our public api
for this first release
um the other challenge is expectations
um instead of right again museum data
isn't very useful um without being
combined with other data sources there's
no easy open gov model for reuse to
apply
uh there is no when is the next bus
arriving app to make acme has tried to
build the scaffolding in the data to
make it easier to connect with other
public and private data sets to make the
data we hold more useful but understand
that this is not in the general
operations of the museum so needs
automation and tolerance for error for
example
uh when we're pulling in metadata from
imdb or
tdtmdb or wikidata ids
that's not part of acme's cataloging
process but added later so they're
essential for making acne's data to be
able to be work with um but sometimes
there are some errors in that auto
linking
um data creation is slow so even though
we've got
an automated uh transcoding setup at
acme now um digitizing a film from the
analog film takes about four times the
runtime of that footage in star flavor
um so seb also writes on that cataloging
a film takes significant research time
especially if the film is unique to us
along with some or all of the people
involved are featured in the film
because data creation is slow we also
have records that are very old and
featured feature language that was
common
in common use in previous decades that
may be considered offensive or
inappropriate in modern time remember
that acme was the state film archive all
the way back to the 1940s this means
that there is
internal concern about what previous
language might say about us now and this
creates more work to fix the data these
are human cultural issues that manifest
in risk aversion
another challenge was just the sheer
update time so updating 45 000 records
and doing some uh changes to them takes
about four hours so we run that update
overnight which is great um but if we
need to do any live fixes then yeah it
takes about four hours so we've got a
bit of a turnaround time there
uh and also the
uh
we get the nightly get diffs on 45 000
files uh sometimes fails on the pods
because they've got a limited amount of
memory so
um we've got a bit of a struggle keeping
the resources really low and then making
sure that the diffs don't kill the pods
uh thank you um i'd also like to
acknowledge the excellent work done by
our original team who built the private
xos apis so
uh ali haberfield andrew sarong benjamin
ladd david amores uh greg turner the cto
at the time uh pipshi uh and myself and
also want to acknowledge our new
developer sam mayer for his help through
this process which has been excellent
um also a shout out to our bosses so sub
chan magazine guy lucy patterson
brilliant uh francesco romini uh who's
my direct boss uh who puts up with me a
lot which is great
um if you'd like to see the slides
there's a link to them there so s i g
hmon.com
acme
um
and that's it any questions
thank you simon we've got a few
questions for you
um are you asking users to sign in or up
uh so you can get some usage stats at
all or are you just providing http
access no it's totally open so um we
thought about
doing api keys and that sort of thing
um so at the moment we've got absolutely
no analytics on people using it other
than how much cpu load
is on our pods at the moment so we'll
keep it like that until we need to worry
about costs or anything
um is there a skew to the data that is
being looked up anything interesting or
surprising or any new apis you've been
asked for
um we haven't actually had time to look
through the data ourselves yet so we've
just been building this thing um so i
suspect we
as we work with different universities
who are going to do projects with it um
we'll find out a lot of cool things
um sorry what was the second after the
question
um is there any any new apis you've been
asked for
nothing we've been asked for yet but i
think um our creators api and our labels
api
are probably the logical next ones but
yeah if anyone else wants any of our
other private apis i mentioned opened up
then definitely email uh because that
always helps me
get the bosses to prioritize it so it's
gonna be really useful
um
another question here i'm curious as to
how you support and build relationships
with users how do you approach
documentation community and building
awareness of your data availability
um yeah so we've got uptime monitors to
make sure our api is um up and um
available
but seeing it's brand new we really
haven't
had that many problems yet so if you can
crash it that'd be great and we will uh
please get in touch if you do and tell
us how you crushed it so we can we can
make it more stable
uh in terms of building community um
that's a good one uh giving talks like
this um we're hoping to connect with
other organizations um the state library
and melbourne are doing some really
interesting things with machine learning
at the moment and auto categorization so
it'll be really great to work with
people who are doing
tagging
and categorization
because that's what we need help with in
our collection
um have you had any data sovereignty
issues being raised around the use of
commercial cloud services like aws or
google
as you've worked through getting your
public api up and running
uh i haven't yet that's probably a good
one for seb chan to answer so um yeah
ping him
chan on twitter and ask any questions
like that he's he's a good one for those
wonderful and one last question have you
had any issues with lawyers not
understanding floss software licenses
i.e coming from all software must be
licensed or else it's stolen model
or insisting that a signed license or
non-disclosure agreements
but then adding exceptions
that sort of thing
uh we haven't yet touched wood so i'm
sure
down the track
as we try and release images and videos
and a lot of other external content then
um yeah we're going to run into a lot
but i think we took a pretty cautious
approach with this first
dump of data where it's all just stuff
that we've created
ourselves
wonderful well thank you very much um
[Music]
oh sorry i keep going you said but you
keep mentioning said that's probably why
um simon will be available in the go
glam chat functionality which is to the
left hand side of your screen but we
will be moving into
katherine's session which is at 2 p.m in
the video chat session called go glam
dash shovel ready glamor graduates
so i'll see you all there at uh 2pm
thank you simon
thanks so much
thanks