 Hello, welcome. Thanks for coming, everyone. So we're going to get started. My name is Benfina Radden. I'm from the Museum of Modern Art in New York. And this session today is part of the Open Source Digital Preservation and Access Stream. And we are very excited today to share with you a bit about what we've been doing at the museum to build a system for housing for our digital collections. This is a project that's been going on for many, many years, although we've only actually been building the thing itself for the past year. So it's a really exciting moment right now. And so the way this is going to go today, I'm going to hand things off in a moment to Cara Van Malsen from AV Preserve. And Cara is going to talk a bit about the history of the project and our kind of planning process, how we kind of figured out what we needed instead of just kind of shopping around for solutions. We're going to talk a bit about our process of producing a request for proposals and the kind of different companies we looked at. And then we're actually going to show you the system. And then we will hear from Dan Galeen from Artifactual Systems. And Dan will be talking about the development methodology that was used in building our system. And that will be it. Let's get things off to Cara. All right, hi, good afternoon. I'm actually going to try to use a timer. Okay, so I'm Cara Van Malsen from AV Preserve. And I'm just going to give you a little bit of the back story to explain how we got from there to here to where we are today. So we have a timeline on the screen. Going back to about 2008, and that's around the time that I initially started working with MoMA and Glenn Wharton at the time was a time-based media conservator. They recognized, you know, there was definitely a need for something to better manage the digital collections at MoMA. And these are the fine art and art and architecture collection design collections. So I'll just show in a minute that the collections were growing at a very rapid pace. And so at the time, we sort of started trying to come up with what we really needed to do. So the first thing we really needed to do was develop our business case to present to the management, to the administration, to start to get support internally, to kind of define the problem and articulate what the solutions were, what we needed to better manage the collections. So that was really the first step. And that's why that timeline slide kind of goes quite a while because that was a slow process and it took a good amount of time. You can see on this slide a couple of things. The collections at MoMA were growing quite exponentially. The graph on the upper left-hand side, if it's hard to see in the back, is the time-based media acquisitions at MoMA starting back from 1970 on the horizontal axis up to 2012. And so you see a big spike there, which is, you know, definitely growth in time-based media coming into the museum. It wasn't just that time-based media was increasing. All acquisitions were increasing. But with that came a lot more time-based acquisitions as well. At the same time there was also an increase in software-based artworks. I'm sure many of you are familiar with MoMA's acquisition of video games a few years ago and the continued development of those types of collections as well. So more complex material, more large data, that were going to need to be digitized, and digitization actually happened in this time frame as well. Spear-hitted by Peter Elixic, who's probably here. He's doing a lot of that digitization work with the video. The conservators needed a way to better manage these materials, to have more automation, to have centralized storage, to have ways you could do processing that weren't so manual and hands-on. How can we do this more elegantly and more automated programmatically? Around late 2011, I think it was go ahead. The museum said, you have our support. Why don't you start figuring out what it actually is that you need? What is the system that you actually want here? We started developing a system specification of what is now called the DRMC, the Digital Repository for Museum Collections. What would that actually look like? We went through a process to make this happen, which began with involving all the stakeholders. We gathered relevant stakeholder groups around the museum, conservation, AV, IT, the group that manages the collections management database more. All those people together. In total, we had about five departments and 13 interviewees and started to understand what their problems were, what their challenges were, what their visions and goals were for a solution. We started collecting all of that data. Out of that, we began to enable us to articulate some requirements and use cases. System requirements are very granular functionality that we needed to have. Very, very specific, as much as possible. Use cases are stories or narratives that illustrate how a user would actually use the system to accomplish a task. It really is a way to communicate to either to developers who might be building a system to meet these needs or to evaluate existing technologies that might be on the marketplace to see if they'll meet your needs. It's a good way of expressing what those needs actually are from the perspective of the user. So, we ended up with 55 functional requirements. This is a little bit higher level. You could definitely get down in the weeds and go much, much, much lower, but at the time, that was serving the needs quite well. We had 22 use cases, which is quite a lot illustrating everything from how do we create SIPs, which is a term coming from the OAIS standard for submission information package, doing integrity checking, fixity checks on the files to make sure there's no corruption in the data, things like search and browse, what should that look like, or how should that interaction be. Somebody says, oh, we want the system to do search, we want faster than search. What does that mean? What do you actually want that interaction to look like? That's what these use cases try to spell out in a little bit more detail. At the same time, we also wanted to make sure that the community at large was that we were able to benefit from some of the expertise out there, especially those groups that had been working with complex media and digital preservation environments for some time. We engaged six external advisors for a meeting, and some of those folks are actually in the room. We have Howard Besser, who is in the back, Hannah Frost was there, and Ben was there. At the time, Ben was at Rhizome at the New Museum, so it was very serendipitous actually that he attended that meeting. In mid-2012, we finalized the specification based on the feedback from the experts. They said, yep, looks pretty good. Now what? Around this time, mid-2012 to 2013, a lot happened in the interim. One great thing is when you have a specification, you can sort of start to understand what you need to fill. Think about ways that that might be accomplished. It might not be that we need to build a giant software system. Maybe there are existing elements of this that could be filled in other ways. What we knew was we have the TMS collection management system and the dam, which is used for providing access to images of artworks, photographs of a vase. That's the purpose the dam was serving. We were actually able to use that spec to evaluate those existing applications within the museum's environment and see if they could meet the needs at all. What we found was we really had a lot of gaps in those systems and they weren't going to meet the requirements for the digital collections. We knew we needed storage, we knew processes, we knew processing. There definitely needed to be a database component and an application layer to allow the users to interact with all those things. During this time period, the storage was acquired, dedicated conservation storage. They added a team member which is Ben. That was actually a huge part of making this successful. The services bubble got filled by an application called Archivematica which is an open source application that actually is developed by Dan, which Dan represents, but that's another story. While those components were in place, there was still this sort of missing piece. It's just this management application layer. What is the layer that's going to allow the conservators to manage the collections and understand the collections well and have that automation and really to be able to do some analytics reporting and things like that. In mid-2013 it was decided that requests for proposals should be issued for software development for this management application layer. What we did was we kind of did that same process, went back to our requirements use cases, sort of refactored and refined them. It had been a year later. We had a lot more existing components in-house now at the museum, so we were able to kind of look at that and say, okay, what do we need, what's missing and try to spell it out. We issued an RFP that kind of laid out all these components. That went out in April of 2013. I'm going to turn it back over to Ben to continue the story of how that RFP process went. Around this time, we released this RFP. We sent it to five different firms, which actually is a pretty small number. Interestingly enough, two firms dropped out after they actually read the RFP in requirements. And I think that actually speaks volumes to kind of what we were seeking to do here. It was seen by some pretty serious firms, software development firms as very risky. There were some requirements that while they were defined, saying we need to be able to do this, how that could be done was very ill-defined because we wanted to have a methodology in building the system that was iterative and sort of experimental. We wanted to learn as we were building. And some of these firms felt that that was risky because it could mean going over budget or not being able to actually finish the project and things like that. So of the three firms that did make it through to actually saying, yes, now that we know what you're doing, we want to work with you, they were sort of three different sizes. There was a very, very large vendor with thousands of developers offshore locations, 24-hour phone support, and a firm that MoMA had worked with extensively in the past and still does today for other projects. There was a medium-sized vendor who had also great experience with museums and they were about a team of 30 to 40 people. It was a very small team and that was artifactual systems. So when we were the vetting process for these RFPs, it was really kind of designed not just to see their portfolio past projects, but we had some small deliverables that were really designed to see what is the quality of your product specifically with what we want to do but also what does it like to work with you. And with these kind of ill-defined kind of digital preservation concepts, how do you wrangle those? And what we found was that the other two firms where they really, really felt sure it was in domain expertise, artifactual systems was unique in the sense that they're composed of developers, trained archivists, information scientists, systems engineers, like a really unique team that general-purpose software development companies simply don't have. And we felt that if your team does not include the kind of deep knowledge that the client has internally, if that firm doesn't have that it's just not going to work. So we it was interesting in the sense that artifactual systems represented a vendor that MOMO was not used to dealing with as an institution. They were small, they were young, and what we were seeking to do was build something new, a new application from scratch, whereas in past artifactual had focused on their two core products, Archivematica and a system called Atom. So we did see this as a big gamble, but simply put the domain expertise was invaluable. So the relationship began between the very, very big institution and perhaps the suspicious institution of and the small vendor. So now I'm going to hand things over to, oh wait no, no, no, I'm sorry we're doing things differently this time. I'm not handing things over to Dan. We're actually going to show you what we built. So we're going to demo the system now and after that we're going to hear from Dan in terms of methodology. So what we built and how we built it. So the first thing I want to show is and I'm sorry you can't see this in the back. We're going to post this online later but the first thing I want to show is just basic search and browse functionality. So this is the first thing that the user sees when they log into the DRMC was that dashboard you saw but this is the search and browse page. As you can see our unit of information is the artwork. This is not an archable collection. Each of these results listed you see is an individual artwork. And on the left hand side here we have various facets that are kind of a mashup of data pulled in from our collections management system and the really detailed metadata that Archivematica produces. So this is really the point of this system. Archivematica produces these great archival information packages with very rich metadata but that's just an XML in a bag. And that's not very useful in terms of search and browse and managing collections. So here you're just seeing a demonstration of the facets. I limited results to only show artworks that were in the media and performance art curatorial department. Now we're viewing works that were created in the 70s from that department. So this is all again just this is not metadata that Archivematica is producing it's all coming from TMS and that was a really fundamental design decision in building the system. We didn't want to reinvent any wheels internally at MoMA we wanted to work with existing systems and maintain TMS which is our collections management system as the system of record for the collections. So here you're seeing works from the same curatorial department based on when they were collected. And it's the interface is pretty snappy it's very fast we're using AngularJS for all of the front end so it's very responsive and Twitter bootstrap for all of the basic architecture of the pages. So now we're going to show you what the page actually looks like for an artwork. So we're going to look at Boomerang by Richard Sarah and Nancy Holt. So the artwork record has a few basic components. The title, year and artist main image and the core metadata sort of the tombstone metadata the basically what you would see on the wall text that's all pulled in from TMS and then what we have here is called the context browser that's what we're calling it basically in TMS if you're familiar with it artworks have components a component in this case is a three quarter inch umatic tape. There's several of those and there's a lot of tape there are also components in TMS for the digital video files. So we pull those in from TMS and we correlate those with the archival information packages and this interface is used for cataloging and expressing the complex relationships between these components for instance the fact that this specific digital file was created from this specific tape is a very very important distinction of course to know and to have and to visualize and so this is also the interface to the actual digital objects themselves. On the right hand side is the file listing so as one is clicking through this graph and exploring the metadata associated with these components the files associated with those components is listed. Clicking a file gives you a basic digital object viewer if it's something that is playable or viewable in a web browser and on the right hand side here we have the characterization metadata so in our case we've chosen to use media info for our characterization of digital video but of course if you are familiar with Archivematica that's a decision you can make for yourselves you can add whatever tool you would like for characterization. So next what we are oh and here I'm just showing also you can download the original master so of course you're watching a derivative when that was playing in that player and that derivative is produced by Archivematica so Archivematica generates these archival packages makes derivatives for viewing and access obviously not for exhibition purposes they're not of that level of quality but just for basic reference but if let's say one wanted to make a ProRes file for exhibition you would download the master and produce that locally at least that's our current workflow and as you saw when you download original files the full quality masters we require users to actually say why they're downloading something so we have a permanent record of who has ever downloaded masters when and why. So next we actually something that we find we need to do quite often is compare the characteristics of two given files let's say the artist gave us two files they look exactly the same and we're not really sure why so comparing the media output is one really quick way to really see what the difference is so we can multi select two files here and it just shows the characterization for those two files side by side in this case we're doing it with still raster images with TIFF images and just showing some of the functionality of the digital object viewer there are multiple files you can cycle through them so to now that we've shown the characterization to go back to the search and browse as I said we are indexing that characterization metadata all of this information produced by Archivematica so as you can see there are facets for format, video codex audio codex, chromosome sampling all that stuff that media info produces you can use when you are searching and browsing so if we say only show me artworks in the department of architecture and design when you scroll back down to these characteristics facets the numbers have updated so it's not here for reporting purposes but it is for basic assessment it becomes really easy to see in your entire repository if you have something that has an inferior bit depth or chromosome sampling or sample rate what have you but we do also index and provide that same information in a more report based format so to go back to the dashboard the dashboard is built of various widgets the first widget that we are looking at here is for fixity checks so we worked with artificial systems to build a basic fixity checker that will iterate over the entire repository and check for fixity at the file level we are doing a SHA 512 and that widget here we are just showing the full log for fixity checks this widget basically reports on ongoing fixity checks and past fixity checks here we have recent activity in terms of material that was recently ingested and material that was recently downloaded next we have some visualizations pie chart showing the various curatorial departments and their representation in the repository pie chart of all of the AV codecs in the repository and a pie chart for mime types this line graph is illustrating the rate of ingest on a month to month basis so it is just showing the fluctuations of activity in terms of how much we are storing this is actually visualization of collection dates so that actually the graph that Kara showed earlier of course it is not complete because we don't have anything in the repository yet we just finished building it so to be clear this is all test data and now below here we have another line graph of ingest activity but this is it adds on the values every month so this does not show months to month fluctuations but overall trend lines and then the widget to the right this is actually it is a bit odd but what we decided to do is we wanted to understand are the total is the amount of storage required for a given artwork kind of trending in any way over the years are artworks requiring more space of course they are we are getting HD video now instead of SD but what does that really look like in any case we are now showing reports we have full reports for ingest activity, download activity fixity checks and this one is video characteristics so it is basically our characterization output just in a tabular format it can be downloaded as a CSV so if you want to do some more advanced visualizations or analysis on it you can do that but it is a nice basic visual sort of like at a glance thing so lastly is user management so in the upper right hand corner there is my username and specifically at MOMA we have integrated with our user system which is Active Directory at MOMA and we have four user groups so people can either only view things and not edit any metadata or download any originals they can just play things in the browser or they can play things in the browser or they can just edit metadata so perhaps a collection specialist that doesn't need access to the actual artwork they just need to see it and catalog it and then the third category is basically full access except for administrative duties so they can download everything they can edit everything they can view everything they just can't manage users and things like that and control vocabularies and taxonomies the demo so now I'm going to pass things over to Dan and he's going to talk a bit about our development methodology sort of like how we actually got there Thanks Ben so as Ben and Kara have outlined in this process a lot of thought went into MOMA's selection process and I think that it's these initial steps that really made Artifactual want to work with MOMA on this project as a firm Artifactual is most known in the US for our work with Archive Matica but we also maintain another project called Access to Memory or ATOM which is an open source web based description and access platform we have a skilled and passionate team of archivists and developers currently we're about 17 as Ben outlined and we had seven people working on the DRMC project full time with contributions from other team members as needed throughout and the strengths of our proposal to MOMA was in pointing out how much of the functionality that they wanted already existed in ATOM as such when we originally made our proposal the idea was to build the DRMC as an extension of ATOM however we wanted to make sure that the DRMC would remain viable in the long term regardless of what happened to ATOM as such we decided that we would abstract all DRMC code from ATOM and use it as a sort of back end dependency that could be swapped out in the future with minimal effort if needed Ben already outlined some of the technical details but we're using a MySQL database in the back end we're using Elasticsearch for our search index and we're using Twitter Bootstrap and AngularJS in the front end for those of you who are interested one of MOMA's requirements in the RFP was that the Agile methodology be used now Agile is a development methodology that focuses on iterative development short term sprints of development that are focused on concrete goals and deliverables which are regularly set in front of the client for review and then this feedback informing the next round of development this methodology was new to our artifactual but one that we saw could be extremely useful for us as a company moving forward at the same time we wanted to make sure that before we began development we had a clear sense of where we were going consequently the way we decided to divide things up was into two phases planning and development phase one which took place in July to September of 2013 was focused just on the initial design this was followed by a site visit in September 2013 to review this and then from October to December of 2013 we built an initial prototype to see how those first planning phases transfer from paper to the screen phase two the active development of the project took place from January to June of 2014 following Agile methodology we then divided up phase two into a series of sprints there were five sprints in total each were developed with I believe six or so concrete deliverables we planned each of these deliverables to be done in a sprint in about 300 hours which is what we thought that our small team at the time could handle in a development phase in addition to this we also had weekly internal project meetings and these were also followed up by bi-weekly reports by our project manager David you has and a telecom with Ben to review the process as we move forward so if there's one take away I can share out of this whole process it's this if you want your final deliverable to go beyond just the most minimal requirements you need to expect to be deeply involved in the process Mona understood this from the outset and I think that this is one of the reasons why they insisted upon the Agile methodology so I don't expect you guys to be able to read this but what I'd like to show you here is this is just a screenshot of one of the comments on our issue tickets and our development tracking system the only thing I want to get across here is that in addition to daily discussion among the developers you can also see regular feedback from Ben throughout the process there's simply no way you're going to be able to hand off a set of requirements to accompany no matter how large or small they are and expect to get an ideal solution returned to you without involving yourself in the process many of the ideas that seem ideal on paper just don't work the same way that you expect when you finally sit a user in front of the screen for the first time the Agile approach makes allowances for this from the outset so that the application can evolve as it's developed and that feedback can be incorporated as things move forward so just to outline this process and how we follow it briefly on the left here you have one of the user stories or use cases that were developed by MoMA in the initial stages the first thing we did at Artifactual was to transform these into more visual based workflows so we could see what exactly the user would be doing how the application would respond and where we felt we actually had to have a look at what the application interface would look like to understand what was going on from these workflows we then transform them into wireframes so that we could see that in action and work out what interface elements were needed this wireframe on the right shows a user searching for a particular artwork record these wireframes were then used as the basis of development so on the right here you can see the application as it was about two months before code freeze as you can see many elements ended up exactly as they were in the wireframe while other elements had to change as we tested things and found out that they needed adjustment this is exactly the strength of the agile methodology testing feedback evolution in addition to this development methodology MoMA made sure to invite feedback from the broader community to ensure that we are on the right path with what we were doing this helped ground all development process in feedback that was broader than just the specific use cases of MoMA's requirements and make sure that we were getting advisement on elements such as architecture usability and design these included an experts meeting in December of 2013 who conducted a suite of usability tests on our initial prototype and a technical advisers meeting which took place in March of 2014 with experts of the members of the digital preservation community for the usability testing was also conducted in April of 2014 in all these sessions were invaluable to both Artifactual and MoMA and I think really helped us build a much stronger application in the end of course there's always going to be some unforeseen challenges when you finally sit a user down in front of the software for the first time it's important to remember the complexity of some of the problems that we are trying to solve here as far as I'm aware we don't know of another application that's trying to solve these exact use cases as well as some other existing repository software applications will allow you to create and interact with your AIPs but there's not much that will allow you to manage the relationships between related AIPs the software dependencies that are required to preserve and display them and the artwork components to which they relate on top of that as Ben has just shown you in the demo we were trying to package all this with user friendly reporting and a user friendly interface as we move forward in our development we learn to be much better about avoiding scope creep this is part of this as an understanding the difference between developing a new application from scratch and working on features for an existing one it's important to understand the first phase of development is all about the architecture, the building blocks those moving pieces the refinement and perfection can come later as such, I think that MoMA became much better about accepting minimal viable product as some of our initial phases and we all learned to keep the focus on the big picture as we move forward we also began discussing the possibility of future rounds of development so some of those more finer pieces could be dealt with down the line one of the last things I want to show you guys here is one of the initial wireframes this is the wireframe that we submitted with our RFP you can see now that you've seen the demo on how things turned out how far things actually came along along the way had we developed the application like this initial wireframe it would have met the use cases of MoMA and I think that perhaps this is maybe the strongest argument that I have for the agile methodology that ultimately the solution that we hit upon was much more intuitive and user friendly in the end we might never have reached that without this cycle of evolution throughout the development phase finally I just wanted to mention about going forward what happens next a lot of that has to do with all of you Artifactual is as a company committed to open source development and standards based development this is what we do with all our projects however in this initial development phase MoMA has built this beautiful new application and we want to work with others with it but at this point in time it's been built on a specific use case what we'd like to see happen next is to find other development partners other people in other institutions who are facing similar challenges but with different particular use cases so that we can generalize this application open up the code and make this available to the broader community trying to back over to Ben now great thanks Dan yeah so let's take a minute to step back and like end here so you had a large institution like MoMA that had a really tough problem we have huge huge video film software based collections just tons of stuff small media conservation team hard to manage so what do we do do we go for a melon funded project build some new software from scratch spend two million dollars no we found some existing open source things that kind of did what we needed and just modified them enough to do what we really needed in the end and we built some stuff from scratch but I guess the real important thing here is what is gained by going open source and I think that's A there really was there's a clear financial discrepancy of what this cost us and what this cost similar projects not to name names but I won't name names but I'm sorry but anyway so the point is while this was not free as in beer as the open source parlance goes it did cost a significant amount of money software making software is not free it takes people and people's time but it was quite affordable in the broad scheme of things and what we're left with in the end is this software that is going to be available to anyone and as Dan said it's not at the moment very useful to everyone because it is very moment specific it's tied to TMS it's tied to our user system there's probably other things that I'm not thinking of but it can easily be generalized and will become essentially something like Archivematica that you can just download and start using and of course the software doesn't solve all your problems you have to have good storage you have to have good IT to support the software you have to have good users that know how to use it but policies yes good policies and one really important thing that we've been doing after having built this is we've been doing kind of a informal audit with AVPS kind of looking at what we built and then looking at the standard for trusted digital repositories to see how does this actually line up according to those like really intense standards so policies are that's really our big thing right now we've rolled this out in production and we're starting to put stuff in it for the first time and that's making us realize oh what's our policy for this case or that case I think the really exciting thing though is as other institutions with similar problems you know similar time-based media collections with complex relationships and dependencies and whatnot start to adopt this you know it's going to become something bigger than what we imagined and I think that's really the importance here you know we don't want to own this thing we want to see it become something that we you know bigger than what we had imagined so that's it we're going to open the floor to questions now thank you so much for coming question yes well what we decided to do is roll it out with the recommended values from Dublin core for expressing relationships and we know that's not going to work like that's not going to express relationships of AV materials and software based art but we kind of want to take things as they come and sort of when we encounter a situation where that does not meet our information needs we can sort of look around then but I should actually mention that we do have a national digital stewardship resident currently at MoMA who is looking specifically at process history and capture metadata standards for AV materials so how can we express this file was made from this tape in a standards based way but also in a user friendly way and she will be producing a report of the results of her study probably this spring any more questions yes well we still use TMS for creating the artwork record the record of the artwork in our collection yes because the creation of those records at least in our institution is done by either collection specialist or registrars but this is a system that's just used by conservators so we need to kind of view the materials in a very artwork centric way but it's not a place for generating collections metadata but that being said in terms of generalizing the software that's certainly one aspect that could be critical for some institutions where they're saying well we don't even have a collections management system so this easily could be kind of modified to an extent where this also did serve as your collections management system and that was where you did that cataloging just to add to that a bit access to memory the underlying software that we sort of built this as a part of our approach in that for description and access is template based so we do have templates for standards such as the ICA standards we have all the ICA standards we have a mods template we have a DAX template so porting these over and it manages digital content as well so porting some of these templates over into the DRMC is definitely a direction that we'd like to go next we do have a basic Dublin core template already in the DRMC which is used for creating supporting technology records so if there's a dependency perhaps this artwork requires this specific media platform to be used and you can create a new record in the DRMC using that and we'd like to see that adapted and broadened so that you don't necessarily have to use another application such as TMS to create your records I'm glad you touched on that feature actually because that's something that I forgot to include in the demo and it's one of the most important features so one of the problems we have of course is that complex software based artworks often have dependencies that are external to the work themselves like they need to run in this operating system or you have to have this codec installed on the computer the video is playing on and those materials or those dependencies are often not specific to one artwork they're shared by several perhaps so what we've done is we've created a way like Dan said that you can create records for those technologies only in this system and then those materials are ingested so you can express a relationship between an artwork in an operating system so we're excited to start really creating that data because it's going to create a pretty cool set that could be used in a lot of different ways besides just getting it to work Any more questions? Chris? Are other museums actively looking at adopting or adopting this? Well the question was if any other museums are looking at actively adopting or testing this and so MoMA is part of what's called the Matters and Media Art Consortium which was founded as a result of the Cremlix this private collection essentially creating this trust to gift a lot of time based media to these various institutions and as part of that the institutions realized we don't know how to deal with this stuff this was years ago now well 2007 in any case SF MoMA, Tate and MoMA we all kind of talk very frequently about these things and we know that they're interested and they're excited to see it and test it but the fact is the code's not on github yet because it's MoMA specific and unfortunately it's hard for us to justify paying for the development to generalize it for others it might be selfish but it's a hard decision to make when you have a limited budget so yes but they can't test it yet because it's not online yet yes I mean that really varies it depends on what we're talking about if we're talking about digitization then absolutely we would provide very specific specifications to a vendor who's doing digitization for us but if we're talking about material artist it's a very different scenario so in media conservation at MoMA we have some initial conversations to try and understand how the work was created so that we can understand we don't want to collect what we think is a good archival digital format we want to collect what is based on the way the artwork was created it's equivalent of a master file so we don't want the artist to do any transcoding or normalization on their end that could perhaps alter the work in a very significant way before we even get it and we're not doing any normalization for preservation purposes on our end yet a policy based way of saying take any video file that we get and transcode it to this specification Archivemetica allows you to do that at any granular level in fact not just you know transcode to all video to this you could say transcode this to this and this to this and this to this but we're kind of waiting I guess to get stuff in our system first and we can always reingest if we need to normalize for preservation at a later date but we feel that there are significant transformations we have a lot of research to do before we can do that on a policy based like totally repository wide level yep in the back yeah I wish Katie could speak to that oh she's still here can you repeat the question well he was asking about about star and if there's any so well I guess I can so the film tour has historically had this database star from the rest of our collections data but the film department is in the process right now migrating that data to TMS eventually it will take some time and we are I mean the the film department has been in an interesting position in the museum it's always been kind of its own entity in some ways with its own staff conservators and doing photo chemical so in some ways we're only just now really starting to bring the film into the fold with the digital acquisitions that are coming in and digital intermediates that are being produced and that's yeah there's a lot more the curators are acquiring we're digital now and not 35 millimeter prints and 16 millimeter prints so we envision that we're including that into the DRMC eventually and that's actually increase the the storage that you all have today yeah it's really fully bringing the film department into the fold has totally changed the landscape our collection currently is around 75 terabytes and I'm sure you all heard about the Warhol Digitization Project and that alone is going to around half a petabyte and then with the digital intermediates the film is producing that's an additional potentially 40 terabytes a year so it's a big thing and we didn't mention it here today but we are moving over to a new storage system that is more designed for these massive collections of data we're moving to hierarchical storage management where mainly everything is on LTO 6 you know but recently accessed and stored materials are on spinning disks so something that isn't just you know spinning all the data on disk currently because the fact is that these things go into storage and they might not be touched for another 50 years it's really you know based on curatorial programming any more questions going once going twice thank you