Hello, we're here to talk to you today about Drupal as a digital asset management system and we want to talk to you about our platform Island Dora, but also all of the other tools that are out there in the Drupal world that can be used to add digital asset management functionality to any Drupal site. So we are the Island Dora Foundation. I'm Melissa Andez of the Project and Community Manager. And I'm Danny Lam, the technical lead. And our foundation the project for Island Dora was started in 2006 at the University of Prince Edward Island up here in Canada, a very maritime economy, which is why you'll find little lobsters kind of kicking around in archetype repositories and on our slides. But the foundation was launched in 2013 to take a project and make it more sustainable, make it more of a true community organized community driven project. And our mission at the foundation is to steward the Island Dora software platform, but also to steward this open source community of users and developers that has grown up around it. We'd like to start by talking a little bit about what exactly a digital asset management system or a Dams is and why you would want one. So a Dams is what you need if you want to store a very large number of digital files and then be able to find them and do things with them again later. It's not enough to just dump your content into digital storage and leave it be in a lot of cases. Storage is one of the key elements, but for those files to be useful, you need other aspects to that storage. It needs to be organized. If you've ever tried to sort through your files in your Drupal file system to look for one particular file that was named very clearly, you can probably appreciate why it might be advantageous to go beyond just this one big lump of files and put things into collections. You might be able to share and access those files. This could include having a viewer so you could look at them in place, even if it's a file type that Drupal doesn't natively support. You might want to control access to those files. Maybe you don't want just anybody to be able to download them or you want to be able to see who's downloading and track who's accessing those files. They're going to need to be findable. They need to be searchable and discoverable. So after you've put them into storage, you can find the one you want and take it back out again and work with it. You might want to be able to analyze what you're storing, get some an overview. How many files of this particular file type do I have in my system? How much disk space am I using with this one collection versus this other collection? You might want to transform or enhance your files. Turn them into a more usable file format while you're uploading them. Turn them into something smaller and easier to store. Turn them into something easier to share on the web. Another aspect of that, you might want to be able to preserve your files and transform them in ways that are going to make them more durable in the long term. So put them into file formats and use extraditional tools that will ensure the integrity of this digital data over a longer stress of time, protected from digital decay, but also protected from becoming less accessible because formats and standards drift over time. Technology can change pretty quickly. You don't want to put something into your file storage and then a few years down the road try to go back out and discover you don't have a program that can open that file anymore. You also might not want to have everything in your Drupal file system, all of your eggs in that one basket, by having additional storage options, by picking out important files and putting them in a preservation framework, you've got backups in case things go sideways on you. So if what you're storing is just this digital file, then a dams is adding other aspects to that file that make it more useful. You might want metadata or information about the digital file. So for a video, for example, this could be as simple as knowing what's the file format, what's the size of this file, when was it created, or it could be as complex as knowing who took this video, who edited the video, what buildings and people are pictured in it. What are the usage rights? Is it in the public domain? Is there lessons associated with it? You might want a viewer built into your system so you don't have to download the video and open it up on another program to play it. If you're sharing that video on your website, you probably don't want to share the original multi gigabyte file if it's a really big video. Maybe you want to create a version of it that's smaller and better for streaming so you don't use up so much bandwidth. And if you're trying to do this long-term preservation use case, then you probably want to create yet another version of it that's going to adhere to archival standards or standards that are more guaranteed to be accessible in the long run. There will be a viewer in 10 years that can play that video. These are all different aspects of what you bring to the table by adding a dams to your digital storage. So our dams, Islandora, was born at the University of Prince Edward Island in 2006. The head librarian there had had some pretty bad experiences with proprietary library software. So he knew they definitely wanted to go open source for their dams solution. And they settled on a platform called Fedora. It's a very robust, very flexible digital repository platform. It's open source. It actually predates the operating system of the same name. And it answered almost all of their needs, but the interface was pretty rough. In particular, access control was almost non-existent. It was all or nothing. So they looked at Drupal as having this really nice user interface, really granular access control, and decided to build a platform that would combine the two and let you use Drupal as a front end for Fedora. Not just as the website where you share the things that are in Fedora, but also as the management layer that your library users are using to build the site in the first place. So that's where Islandora comes from. It is a Fedora front end built on Prince Edward Island. So historically speaking, we've always tracked our versions with Drupal versions. So we started on Dora 5, but that's not the fifth version of Islandora. It was the first. And then eventually we moved on to Drupal 6. And I escaped the gaming industry and got a job with a vendor here that happened to work with Islandora. So I got introduced to Islandora at Drupal 6. And then when we moved from 6 to 7, then we noticed that adoptions really started to take off. So this is when Islandora transforms from a handful of sites in Canada and the US to become a really global project. At this point, we know of at least 320 sites across the world. We're on every continent except Antarctica. And since this is an open source community driven project, every adoption also helps to increase support for the platform. We've got a very active peer support community, a list served with more than 1500 people. And this is one of the key factors to Islandora sustainability. There's also a number of very experienced service providers who work in this ecosystem as well. They've got a few years working with Islandora Flavor Drupal and they offer paid support, but they also contribute back to the open source side of the project as well. So much like the larger Drupal community, we're really thriving on the contributions of the people and the institutions that are using our tools. Which is why we like to emphasize that this is free software, but it's free like a free kitten, not like a free sandwich.   You have to feed it. You have to love it. You have to clean up after it. So this kitten, Islandora, is free, but it does still have an ongoing maintenance cost associated with it. So Islandora is used by a lot of folks for a lot of different reasons. These cases can all be solved with a dam's tool and university libraries and archives. They're certainly our largest demographic. It's where we're from. And they deploy Islandora just kind of as a base digital repository. But dams in Drupal is certainly useful for lots of folks out there. And we've been deployed at places like the National Baseball Hall of Fame, the USDA, and even the Smithsonian. So this version that took off with Drupal 7 that got really widely adopted, we'd like to describe this stack as a cheeseburger. So Drupal is the front end. You can say that's the top bun. Fedora is the preservation layer. That's the bottom bun. And Islandora is the meat in the middle. And the, you know, let it... You see, you've gone silent, Danny. I lost your audio. Just kind of cut up mid-sentence. Yeah, you're back. I reset there. I have no idea what that was about. All right. My screen flickered too, so something's funky. All right. Where was I? Resuming timer. Resuming timer. So lettuce pickles, onion, cheese, all the goodies on your burger. Those are all the Drupal contrib modules that you would use to enhance your Islandora site and to add features. So I think this hamburger infographic is quite mandatory. It's certainly easy to, you know, grasp as a concept, but it also does highlight some of the issues with Islandora that have been with our approach to integrating Fedora and Drupal. So first off, this pretty clearly well aligns with the concept of a vertical stack. And really, if you wanted to scale Islandora 7, you were vertically scaling it. You were just shoving more RAM and more processor, more beef, if you will, at your server in order to get it to go to be able to handle the low. You couldn't really break pieces apart and put them on other servers. Also, the way that Drupal is that we essentially replaced the relational database with the preservation system. So we weren't using the preservation system like a preservation system in the relational database like a relational database. And this caused problems. Specifically, we were kind of barred from using a lot of the things that Drupal 7 did really well. Nodes, fields, entities, comments, views, you know, all of these things we were essentially locked out of. And so all of those toppings that you saw, all those contrib modules, those were Islandora flavored versions of contrib modules that already existed. We had to essentially recode all of these wheels. So all of this development effort was essentially being done kind of on top of what all the Drupal community was doing. But it also meant that we were really excluded. We couldn't use those tools. And then the tools that we made, they weren't really usable by anyone else. So when we made the plunge and we jumped from Drupal 7 to Drupal 8, we decided to really analyze what was going on with our stack and with our community and really architect the best solution that we could that really lowered our technical debt, let us take advantage of what was out there in the Drupal world, and also let us give back to Drupal because now what we build would be usable. So Islandora 8, our food infographic, is that it is a bento box, which is a pretty nice compliment for the architecture. I did not come up with the bento box idea. So Islandora 8 is really cleanly separated, decoupled. All the pieces can be split out onto their own server and deployed completely independently. You're not bogging down your Drupal server to do a lot of video processing anymore. It's also very modular. Take and pick what you want. Leave what you don't. And because we integrate it differently with Drupal, now we actually do use the Drupal database for things. Now we have unlocked all of the goodies, so we have nodes and entities and comments and fields and all of this stuff, and we're no longer maintaining our own form builder within Drupal, which essentially is a form builder. If you want to take this all the way to the end of the line of thinking, if we want to take stuff off of the Drupal server and not have it harm your end user experience while you've got a lot of work going on, what you end up is your microservices, which is very buzzwordy, kind of hot these days, microservices. But that's really what it is. Each piece of the software is a custom built and deployable web application with a single purpose and interacts with Drupal headlessly. And although this makes things better for your end users and certainly for your developers, because everything is like nice and cleanly sandbox, it does introduce a lot of complexities when you're deploying it. And so what we've done is we have essentially dockerized all of this stuff. So all of these services, these microservices, these little crayfish, as we call them, these are all available on Docker Hub as images. We even have sample orchestrations for them. And so you can see how easy it is to kind of manage all of this stuff. So here, let me walk through an example, though, of kind of the pattern that we do when employing a microservice. So ETL, Extract Transform Load, programmers will know what this means. The migrate module uses this as an example of what it does. And we're really doing all of the same things, but we're just interacting with Drupal headlessly. So the end user goes, uploads a very large raw video, say it's like 10 gigabytes, something huge like that, right? They upload this massive video. Well, when it's uploaded in the entity hooks that fire, we say, okay, a file got uploaded. And what your Drupal server does is it actually executes an action. It just publishes a message onto a queue, active MQ, you know, zero MQ, you name it, but it publishes it onto a queue. And then the whole rest of the system then kind of kicks in and takes over Drupal is hands off. And we request that large video from Drupal, we pull it down, and then we stream it to the microservice. So I get streamed to a microservice to convert the video into a lower resolution copy or a compressed copy. And then the results are streamed right back into Drupal and made into a media so that it's available on your site. And so we do these types of integrations with all kinds of things. So I mentioned converting video, that's FFM peg, the kind of weird green square there in the middle. But we have a microservice for image magic. We have a microservice for fits. We have a microservice for running OCR to extract text from like scan pages of books, stuff like that. And we also interact with Fedora as a microservice. So we'll talk about that in a little bit because the interaction with Fedora is a bit more complicated, but essentially, our goal is to cleanly integrate Drupal with all of these things. And so that you're not bogging down your server or building just one kind of big massive cheeseburger here, you've got everything broken apart and scaling as needed. So having moved into the world, moving fully into the world of Drupal with Islandora 8, we get to lean on this big field of Drupal contributed modules out there. And there's a lot of things out there that do really core digital asset management functionality that we're not going to build our own version of because it's already been done really well. So we wanted to highlight a few of the tools out there that are really useful for dams in Drupal. Some of these we ship with Islandora and we have like custom suggested configuration. Others we just put up as recommendations, like these are really useful tools for dams. And if you need the thing this tool does, you can just install it and run it. And it works with Islandora, but it doesn't require Islandora. So kind of at the basis of building a dams, you know, we've mentioned that you have to do so much more with the files. In fact, a lot of the work we do is trying to figure out how to cleanly do things with the files. But all of that is kind of, you know, moot if you can't store a very large amount of files in Drupal. And so there's a third party contrib module that handles that it's called fly system. Fly system is actually a PHP library from the League of Extraordinary Packages. And what it does is it's basically a file system abstraction layer. Doesn't matter where your file system is, doesn't matter what type of file system it is, it's all accessed and dealt with the same way. And the fly system module for Drupal integrates with it very cleanly. It lets you expand your public and private file system paradigm with, you know, any other sort of storage you can think of, local disks or cloud providers, and there's lots of modules out there to let you integrate with all of these other vendors and what they do. So Amazon buckets being kind of the big one, right? But then we also integrate with Fedora this way. So Fedora, our preservation layer is treated like a Drupal file system. So when you want to upload your archival copy or your preservation copy, you can just upload it straight through the Drupal form. And it doesn't live in Drupal storage. It lives in Fedora storage instead. Pause the time for a moment. So we're running a little behind at this point. So we need to speed it up. Speed up this section that we took too long through. Some of it was the audio thing, but I paused not long into that. So okay. Okay. This is another really common use case that is actually solved quite nicely by tools that are in Drupal core. So this comes up a lot in the library and university setting, for instance, maybe you've got a bunch of grad students that are going to scan and upload newspaper pages, old newspapers into your Drupal site. And then a different group of grad students needs to come in and add the metadata, fill out all those fields with information about those newspapers. And then a supervisor needs to go and review all of those nodes before that gets published and put out to the public. So having these complex workflows, having different people come in at different parts of the process, have them different levels of access control, all of this gets done with content moderation, which is in core. So it's not a matter of building a new tool, it's just a matter of knowing how to apply the existing tools to your digital asset management needs in this case. A lot of places that deploy Eilendora, they do so as what's called an institutional repository. University will take all of the research output the entire organization, and they'll put all of it up on one site, and that's how they make all of the research available for everything that they've done at the university. And so we found a great way to track views and downloads from your site because researchers are very interested in who's looking at their research. So there's a free and open source metrics gathering server called Matomo, and there's a Drupal contrib module called Matomo, formerly PEWIC that integrates with this. So it embeds in the JavaScript a little tracker that's used to communicate with the server. And then there's also a Matomo reports module, so you can actually view kind of dashboardy statistics in your Drupal site. Another common use case we have, because Drupal is so good at dealing with translated and multilingual content, you want to be able to upload files with non-Latin characters in their names. This will actually destroy a server if you are not prepared for it. So get ready for the white screen of death. If you introduce anything with a non-Latin character in the file name, and it doesn't have to be from another alphabet, you can actually be any kind of just funky, you know, characters, faces, braces, brackets, commas, like all that stuff can just totally tank your site if you're not prepared for it. So there's a great small module out there, thanks to the person who created this, transliterate file names, works perfectly. It converts all uploaded file names into Latin characters. Essentially, it just strips everything down and turns it into a slug like you would with Path Auto, and it just does that way in. So this one's a nice graphical user interface, user experience side of things. You want to be able to go in and change a whole bunch of records at the same time without having to write a script for it. So we lean a lot on views for a lot of things in Islandora, and this is a nice add-on for views, views bulk edit that gives you an actionable view. So for example, I've got this nice collection of cat pictures, they've all got nice metadata on them, I finished uploading them, and then I realized after the fact that I really should have put a subject field on all of those taxonomy terms saying cats, so I can tie them all together with that taxonomy term. I do not want to open up every one of those nodes individually and edit them by hand. I don't know how to do that in the back end with a script because that's not my skill set, but I can build a view that lets me do that and exposes that action so I can figure if I can find all of the records that match particular criteria. I can say, hey, pull up the subject field, put cats in it, click a button, and I can mass update or batch edit my metadata across all of those records. On the other side of that, I want to fill out that same field across multiple records, but it's going to be different information each time. So I've got a collection of cat pictures, but I've also got dogs and birds and lobsters in there, so I want to be able to fill out the same field, but I don't necessarily know it's always going to be that same piece of information. So this is another addition to views called views entity form field, and this gives you a exposed editable field right in the view so I can pull up a whole bunch of records that match my exposed filters, and then I can go through and look at each node in the view without opening it up and edit that field, save them all at once, and batch update across multiple nodes at the same time. So we get a lot of benefits out of the Drupal community for Islandora as a digital asset management system, but the other side of making Islandora 8 as Drupal as possible is now when our community is building custom tools to solve particular needs they have, they're not building just this own little Islandora flavored version of doing things, they're building a Drupal module that anyone in the Drupal community can pick up and use for their own needs. So we also wanted to give you a little overview of some of those tools that have been developed by our community that we can give back to Drupal. Sweet looking zoomable images, this is always, this is a well-liked feature of Islandora. So as a replacement for like micro fish, when you were doing research at a library looking at old newspaper, you'd be spinning the wheels to scan through all of the pages. The modern replacement of that is something called TripleIF, the International Image Interoperability Framework. And if you have a running TripleIF server, we use one called Canaloupe, you can use a also like standards compliant TripleIF viewer and you get this nice deep zoom capability that's quite impressive. So if you check out these images here, you know, you got a cute puppy, you can get in deep on the text, this one's so deep, you can actually kind of like see the pen marks made on the other side.  So we didn't make any of these technologies, but we do provide a Drupal module that integrates the open C drag and viewer, one of these compatible TripleIF viewers with your Drupal content. So if you are running the server, then this we provide as a field formatter, you just go to your display settings and you say, I want this, you know, image entity to be presented as open C dragon. And if you want to do multiple images, there's a special format of a file called a manifest. We provide a block and you can just punch in the location of that manifest and then it will pull down all the images and it will display all of them for you in this nice film strip. So I don't think we mentioned link data too much here, but we do a lot with link data in library lands. So the most common use of link data you would think of is is embedding your meta tags in your page in RDF so that Google will index it properly. But you can do a whole lot more with link data and with RDF. So when you're using Island Dora, you will you are publishing your content as link data. But we also have tools to work with link data out there in the wild. And so the most common use case we have is that if you're using taxonomy terms to tag things, like slapping a cat term onto something to say that this is a video of a cat, well, if everyone's doing that each their own way and they're each minting their own taxonomy terms for it, then there's no real uniformity. You don't know what the authoritative source is. Is this really a cat or is this just what someone is saying is a cat kind of deal. And so what we've done is we've got a module that will actually hook in with your autocomplete widgets and will actually scan the Library of Congress subject kettings. So as you start typing it in, it will actually autocomplete with their taxonomy terms and not yours. And you can use that to categorize all of your data. It's plugin based. So there's a lot of other things that it will integrate with not just the Library of Congress, but that's kind of like the big name. And then we also a community member created an autocomplete endpoint for Drupal that interacts with all of this. So now you can actually share all of your taxonomy terms between your Drupal sites and reference them without having to make your own. This is a really small, simple tool, but it helps to solve that, that analyze need that comes up in, in a dams. So Island or repository reports, it provides a bunch of different chart JS charts that report on what you're storing in your file system. And it can break it down for things like how many JPEGs do I have, how many tips, how many PNGs, or how many videos, how many books, how many PDFs. You can look at disk usage, how much am I putting on my Drupal file system versus how much do I have in Fedora or on Amazon or whatever different storage options I'm using fly system to point to. So it's a lot of really nice, configurable, powerful tools available from trust.js. And then all of these charts, all the data in these charts is also available. You can export it to CSV so you can work with it that way as well. So lots of times folks have a lot of content, but then they want to provide that content in a format so that an aggregator can find it and give you better exposure for your content. Lots of Drupal sites do this with feeds. There are some standards out there that we provide some modules for so that we're compliant with those. One of those is the open archives initiative protocol for metadata harvesting, which is a mouthful, but let's say the digital public library of America will want to be able to read what's in your site, harvest it, and then make that available to a wider audience. So it's just like a feed, essentially, but it exposes all of your entities, your nose, your content as Dublin core records kind of wrapped up in a special rest endpoint. And behind the scenes, really what it is, is its views. You go into your view, you say, this is what I want to be in my feed for DPLA, it will all put all the content in, and then you basically with a plug in manage what format you want it to go into in the views results, and then that's it. So it's a lot like a feed, except it's for a very specific format to get you into library aggregators. This one's born out of folks using Islandora as an institutional repository or as a research data management platform. So they're storing research data or scholarly publications in it. So in that example, maybe somebody out there has written another paper and they're referencing your paper, they're referencing the research data that you stored on your site, and they've got a link pointing back to it. But you get a takedown notice telling you that, oh, you had confidential information in that file set, you need to take it down, it cannot be on the web. If you just delete it, then that other paper out there, now it's got a broken link in its references, and there's no explanation there, it's just, it's digital decay. So this tool allows you to replace that 404 page with something more informative. So instead of that link pointing to a broken link saying, here, it can say, well, this is what used to be here. This is when we took it down. And this is why we took it down. So it's a lot more informative. And instead of just removing the file, you can leave a citation there that now that paper is not just pointing to a dead end, it's pointing to an explanation. And this is also configurable. This isn't just replace all of your 404s. This replaces things contextually so that you can have this take place where it's relevant and not at least a drop of a line. Okay. So I guess the last use case here we're going to talk about is fixity checking, which is kind of a odd way of saying just making sure your files haven't gotten corrupted. So there is a solution that a community member has built called riprap. If you don't know what that is, the riprap are like the really large stones that you see along the shoreline to prevent erosion. There's a nice picture of a cottage Melissa stayed at a few days ago that's got some riprap on the shoreline there. But you know, that's the metaphor you're preventing erosion in your digital data, right? So riprap is a server that's specifically tuned to look at your Drupal and periodically check all of the files and make sure nothing has changed and nothing has been moved and nothing has been deleted. So a lot of file systems will do stuff with fixity checking if case of things have been corrupted, but they can't handle the use case of things moving or getting deleted by a user and stuff like that. So riprap will just let you know, hey, something happened, doesn't try to do anything, but it says, hey, something's up here. That's what your riprap server is doing. And we have a module that integrates with that for your Drupal site. So in your administrative menus, what it will do is it will actually show you in your views, you'll get big red warnings when something has moved or changed, or you'll get nice big green means go. It's okay. Markings if everything is all right. Finally, I want to show you a few examples of what this actually looks like in use. Some libraries and archives out there that have put this new Drupal island door into production and how they're leaning on Drupal and some of these other tools to solve their digital asset management needs. So we start with the Latin American digital initiatives project. This was done out of the University of Texas at Austin in collaboration with some Latin American libraries and they're following a principle of post custodials in here where instead of taking the records from the record creators in those Latin American libraries, they're just taking the digital copy of the records and maintaining that. So it's particularly important for this site, given the source of the material, that everything will be available, not just the content, but the site itself needs to be available in Portuguese, in Spanish, and in English. So they're leaning really heavily on Drupal's multilingual capability there. And they're storing pictures, posters, newspapers, and pamphlets. But because it's multilingual, these records are more accessible to the communities that created them in the first place. Canterbury Stories was the very first Islandora 8 site to go live. There were a series of earthquakes in Christchurch, New Zealand that were quite destructive and there was a lot of structural damage to a lot of the buildings. And so this motivated people to start archiving and preserving digitally things about the city and about the libraries and stuff like that. So this site really manages the culture and history of the Christchurch Public Libraries. And it's from New Zealand and so it has to adhere to web accessibility standards and it does so leaning on Drupal's accessibility features. And also it has to be, the full site has to be available in two languages, so Maori and English, and you have to be able to see the content and the administrative menus. This final one is the first institutional repository using Islandora 8. There's a ton of them Islandora 7, but Kent State is the first place to put all of their journals and scholarly publications from their staff and faculty into Islandora 8, which means they're using this Drupal First approach and the custom tools that they developed for their site are just regular Drupal sites. This is where we get this OAIPMH tool that is not specific to Islandora. It's a Drupal tool. And they're also working with incorporating other open source tools. So they wanted Islandora as an endpoint for their scholarly publishing workflow, but Islandora is not a journal publishing tool. Open Journal Systems is the most popular open source journal publishing tool in the world. There's over 10,000 journals using it. So they're deploying that for the workflow and then they've integrated it directly with Islandora. So the output from OJS is published in Islandora. So just as a recap, what's in Islandora? What are we doing with Drupal to make it have those dams capabilities? I mean, we've got the list here. I'm not going to read all of them for you, but if you are interested in any of these things that we're doing, the expandable file storage or searching and discovering the link data stuff and integrating with all these other things, the usage statistics and the image serving and stuff like that. You can check it out. We have modules available on Drupal.org for all of these things. And what we're working on next, because this is a living project that's constantly under development, constantly being improved. In the immediate future, we're surveying our user community to folks that are already working with Islandora to kind of get a sense of what their development priorities are in the coming year. So we can coordinate those efforts and build some sprints and have everybody pulling together. So we're not all reinventing different wheels of different organizations. That's how we get this shared platform. But we know in the near term, we want to improve the user experience. We really love the graphical user interface on Drupal and how that puts so much power in the hands of site builders who are not developers. But that's an experience that can always be improved, especially in the dams use case. So building more tools there to support people working through the graphical user interface and making that experience better. We know we want to build more tools to support institutional repositories, because that's a really growing need in the existing Islandora user base. There's institutional repositories that they're using it right now, but that can always be improved. And there's more that we can do to grow that side of things. And we also want to expand our bulk uploading options, ways that you can get lots of files into your system very quickly. And in particular, lots of files into your system very quickly through the graphical user interface. So again, putting lots of powerful tools in the hands of non developers, because it's easy enough to write a script to put all those files in, if you know what you're doing. But if you're a, say a librarian like me who doesn't have that skill set, then being able to use this interface and bulk upload is a really handy tool to have. And finally, of course, we're looking ahead at Drupal 9. We've used some of the tools out there from the Drupal community to kind of assess where we are. And we know that the core of Islandora is pretty close already. There's not a lot that we have to change to make it Drupal 9 ready. But because it's part of this fairly complex ecosystem of different tools that come together to solve the dams use case, we'll be watching a lot of those other tools and their migration timelines before we'll be able to say that we're really ready to have a full version bump. Nonetheless, we do expect we will be Islandora 9 before the end of the year. So that's a very quick overview of what Islandora is and some of the tools that we really love in the Drupal community. So if you have any questions at all, here's our email addresses. We welcome you to reach out. So a lot more information to be had on our website, islandora.ca. We've got a link here to the session evaluation if you'd like to tell us how we did and tell DrupalCon how we did. But we have about nine to 10 minutes now to take some questions from the audience if you have anything you want to ask right away.