>> From the Library of Congress, in Washington, D.C. ^M00:00:05 ^M00:00:30 >> Beacher Wiggins: Good morning. We know we are now back from the summer holidays and we are ready to dig in with the important work that we do. Judith Cannan had to come by the office, I was off last week, to make sure I had not forgotten where I was, and what I was supposed to be doing [laughter], and she happened to see me looking at the flier so at least she knew I remembered there was a program this morning. This is another in the series that Library Services sponsors, LC's Digital Future and You, that is coordinated by Judith Cannan of the COIN Division, and Angela Kinney of ALAWE, who is on leave this week. I am Beacher Wiggins, Director of Acquisitions and Bibliographic Access for the one person who may not know who I am [laughter], and I'm going to kick off this morning's session. The title "BIBFRAME On the Move" is trying to capture the ever evolving development of the Library of Congress' initiative, and foray into linked data. It's a prime initiative. We want to give you a sense of what has happened, where we are, and what we are expecting to occur over the next few months, and particularly into fiscal 2017. So I'm going to give you and our participants, today, I should run those down, and we'll just follow in order. And we think saving questions until the end is better, but if you have burning questions as each one of us finishes, and you raise your hand, we will stop and answer those questions for you. So in addition to me, we will have Kirk Hess from the Network Development and MARC Standards Office, and Paul Frank from COIN, who will play off each other, and give you a sense of the BIBFRAME Editor, how that worked, which is one of the centerpieces in terms of the tools used to work with BIBFRAME. Then we have Sally McCallum, who is Chief of the Network Development and MARC Standards Office, who will tell us about the plans for the next phase of our operation, and I'll give you a very brief background of where we are and then move into Kirk and Paul's taking over. About this time last year I guess it was, I had determined that we needed to do a pilot. Well I guess it was a little bit beyond a year ago, do a pilot to test what we had been talking about, we the Library of Congress, in terms of BIBFRAME. And I was adamant that we move forward, whether we were quite ready or not, and we were, in some respects, not quite ready but we rose to the occasion. So by late 2014 early 2015, we were moving forward, because we wanted to test the efficacy of BIBFRAME, how we could use it and what components of it we could test going forward, and in particular, the ability of our staff to be able to deal with that. To that end, then, we identified some 40 to 45 staff members, both within the Acquisitions and Bibliographic Access area, and in the Special Formats areas, to help us carry it out. And we got a mix of cataloguists, technicians, and we covered all format types, languages and scripts. Monographs, serials, cartographic materials, music, notated, sound recordings, two-dimensional artwork, bringing in our colleagues from Prints and Photographs. We wanted the staff to process whatever materials they normally process, whatever crossed their desks, and we wanted them to do it using the BIBFRAME Editor. But in addition, because the Library of Congress must continue to distribute its cataloguing data in MARC format, they also had to catalogue those same items using the MARC format. So obviously that was going to cut into their time and their production. So production was never a focus of the pilot. We termed an idea, when I talked to the classes that were being instructed in preparation, and the COIN Division did say training, that these spoke with prior needs, one, because we had some development work that we were still doing, and we wanted input and feedback from them, and frankly because they were doing something that was new, and we weren't quite sure what we were going to get out of that. To be prepared, they attended some 16 hours of training, instruction that was being offered by COIN. And the pilot preparation on the technical side then was done by Network Development and MARC Standards Office, and that included being able to create a BIBFRAME-like environment. And that called on transforming the existing MARC records, some 18 million were targeted into BIBFRAME description, so that the participants would have that environment to search against, as if they were in a production mode for BIBFRAME. The outcome was commendable. That did actually convert some 13.5 million records into work and instance records, so that the staff who were participating would be able to do the searching and to get a feel for what that would be like. Sally may go into more detail about that, and how that might change for the upcoming pilot. The BIBFRAME Editor was developed as the primary tool for the staff to use, and we'll get more information on that. The staff used the authorities as they were in LC.gov, and had that as a basis for the authority was created, and how that was going to enact with the work that they would perform. Some-the last number I got was like 2,000 BIBFRAME descriptions that were created. I'm sure that's more like 3,000 now, because one of the things that we did, and what I haven't said so far, is that the pilot ran from October 1, 2015 through March 31, 2016, and during that period, some 2,000 descriptions were created. At the end of the pilot, so that staff would continue to retain the skills that they had developed, I determined that they should develop, devote one day per week to continuing to grade records in BIBFRAME. I also should note that the day it was created, was done in the BIBFRAME 1.0 environment, and all those data that were created will be discarded, because this was all in the test mode. We will think differently about the upcoming pilot, and Sally may speak a bit more to that in terms of the stability of the data that will be created. The next thing that had-well, one of the things that happened during this period was the development of BIBFRAME 2.0, and that is going to be the platform and underpinning that will be used for the pilot going forward, and will be the basis of a lot of the testing that will be going on, not just in the Library of Congress, but also as part of our external partners, that Sally may also touch on a bit. The one thing I should mention before turning over to Kirk and Paul is that work flow didn't change, because staff had to work in both environments, we just overlaid whatever staff were doing in their regular work. So we did not test the work flow, and we have not done an analysis of how BIBFRAME will affect work flow. And the other piece, we should say, is that it also doesn't affect the acquisitions side of it, or the user access to the data that are created. All of those will be components that we'll have to worry about as we move forward. So as you can see, there is a lot to be done. I think we've made great strides in terms of what we want the pilot to do to show that we could do this, that we could develop a tool that staff could use, that staff could actually adapt to. I think we did that. The next challenge for us is expanding this. Do we use the same participants? Do we expand the number of participants? How do we get that training done? One of the things that I want is to make sure we're developing a cadre of experts that we can expand and build on so that as we roll this out. ^M00:10:12 And ultimately we'll have to go beyond Library Services, and beyond ABA, in terms of what we want to do. So with that very high level synopsis, now-well, are there any burning questions for me before I turn it over to Kirk and Paul? Seeing none, then I will ask Kirk and Paul to proceed as they have determined. ^M00:10:42 ^M00:10:46 >> Paul: Good morning everybody. >> [Group response] Good morning. >> Paul: Yeah, I'm not as young as I look [laughter], but it's so funny when Beacher made that comment about, you know, the beginning of the Fall season, I still feel like the day after Labor Day is the first day of school, so all those nerves [laughter] and everything. So here we are on the first day of school. But I'm Paul, this is Kirk. I think of us maybe as Abbott and Costello [laughter], or Sonny and Cher-[laughter] but the point is, pick your duo. We work very closely as a duo, and it was very interesting, because we were facing in different directions, but we had to meet in the middle. So my focus was on cataloguers, right? Reaching out to cataloguers. Kirk's was finding that interim between cataloguing and technology, and facing out toward the technology environment. So it was a very productive duo. And I want to talk a little bit about that. And because of that, I thought it would be good, or it was suggested and I agreed it would be a good approach to have us both stand up here and have us go back and forth and talk about our roles in the BIBFRAME Pilot from last year, and into this year. >> Kirk: Hopefully we can both be heard with the microphone in the middle. We didn't think about the microphone [laughter], we're playing the duo, one microphone. Okay. >> Paul: Alright, so this dynamic duo didn't come into play right away, right? So in 2014, we were given a BIBFRAME Editor to work with, to play around with, to experiment with. We hadn't even thought about a Pilot at LC. We just-here is, here is a product, let's test it out. It was really very interesting. I'm just using screenshots. You can look down the left-hand side, and you see the different formats, records print, bibliography, books, dissertations, paintings. Very broad. On the right-hand side, you could see one of the input screens that you would use in the editor. Really no different from what we did in the pilot, but think about this. You see no code, no cataloguing code represented here. I made the comment in the past that this would be perfect for someone who had, say, a very large collection of sound recordings, personal collections, they wanted to describe them, right? Describe your own personal library. This would be a perfect way to do it. If you had LPs, you could put the album name, you could put the artist, you could put the description, subject, everything that you would need to use for your own library. And beyond that, this could also work very well in a public library environment. A public library could make great use of something like this. But think about the Library of Congress, and the work that we do, and compare it against what we have here. So one other screenshot that I wanted to show you was-and I use quotes here, "authority work." This is how authority work would have been done in this prototype system. It's certainly very user friendly. If you're creating a new authority record, you put first name, last name. I love that, you know, we're not dealing with surnames, or entry elements, all these things that cataloguers deal with. You simply enter in the name. But the funny part to me was the birth date, death date. Now, the comment I made about, you know, I'm not as young as I look, when you have to go online, you're making a profile on some site, and you have to put your date of birth. Well, you don't usually just enter in your date of birth, they give you a drop-down calendar, right? And you go all the way back, and I'm old enough to think I wonder if my year is even on this list that drops down, right? [Laughter] Well, it usually is. But what would you do if you were born in the second century? If you're setting up an authority record for someone who lived in the second century, you're going to have to do a lot of clicking to get to that calendar, and then by that point, what difference does it make that the person was born on a Tuesday or a Wednesday at that point? I mean, it's just, I'm making fun of this, but I don't want to underplay that it certainly had a use. It could not, maybe, be used at the Library of Congress for the type of work that we do. On the other side of the screen you see a new topic. I mean, think LCSH if you're a cataloguer. If you wanted to propose a new LCSH heading, you know, there is a very elaborate way to do that, and certain rules have to be followed, instructions have to be consulted. So the editor that we had in 2014 was a start, but by 2015 we knew that we were going to have a pilot at the Library of Congress. Beacher already gave you a very good overview of what we did. Our cataloguing code standard is Resource Description and Access, RDA, so we had to take this editor and turn it into something that cataloguers could describe resources using RDA with, and so that is where the team came together, this duo, and I'm going to let Kirk now talk about all the things that needed to be done to modify what you see here and what we used in the pilot. >> Kirk: So profile editor. So when you-a few slides ago you saw there was a list in the side of Formats, things like book, or electronic book, those kinds of things. So what are those? Those are profiles. So what's a profile? Well it's basically just a template of fields that are grouped together, and in the original prototype, it was hard coded in there. There was no way to change it. No way to add a new one, other than coding it by hand in JSON, which would be very difficult for people who don't know anything about JSON, or even what that stands for. So we contracted out to develop this tool called the Profile Editor, and this is what Paul and I used to develop some of the profiles. The first one we worked on was monograph, because that's always the bulk of work in technical services. So you can see here there's a name, there's some elements, see at the bottom there is preferred title for the work, and you notice it has these RDA terms. So one of the things we decided to do was use RDA description, and that's something Paul is going to talk about later, but basically the idea there is basically so you know the rules, and you can just enter it in the field, for the rules, other than trying to remember an archaic number, like MARC, the way that MARC works. So another kind of challenge we had was there are many lists of things, as well as lookups for things. So an example of a lookup is a name. We talked about that. Before, you know, you want to find Tim Carlton is an example that Paul always uses, so which Tim Carlton? Well, you know, the one with this date, born on this date. So you can look that up in id.loc.gov, our linked data service. But we want to make sure it's actually enabled within the tool, and so one of the things that was enabled within this system was that at the bottom of the screen, you can barely see there's something-values, there's a URI there, which is a lookup service. So zooming in, so that's actually the URL you can go to in your browser, and it goes to the linked data service, and you can enter in a keyword or a name, and it will look up, and you can see names there. Well, it works the same in the editor, and that's how it was keyed in. One of the things Paul wanted me to mention was that when we originally did this, all the lookups while we could add them to the profiles, they were hard-coated into the editor by the previous instance of this. So if Paul came up with a new list, he had to tell me about it. I had to go in the code, I had to write more code to add that list, and in addition to we actually had to load it into id.loc.gov, so eventually we realized there were many lists that were already in ID, but we couldn't use them, because you had to do this whole process. So I figured one of the things I added was the ability that any generic list that's an ID could be accessed through the tool. So that was another little challenge we had. It ends up that there are certain things that are a little bit different, depending on the results. So in this case, you're searching for a name-those had to be a little bit more specific. But if you're just looking up a code, what's another one, like format, format is one thing that we had-[inaudible], those things were just you could put in there. So let's see. So I think Paul is going to talk about now our Pilot. >> Paul: Right. So while Kirk was doing all this work with the editor that you saw, or hopefully saw on the slides, we were gearing up for this Pilot. Beacher said 40 to 45 cataloguers, LC cataloguers, all RDA cataloguers at the beginning, and we added on some cataloguers who use DCRM(G), a little bit later, to test another code in BIBFRAME, but in order to have the Pilot, we wanted to at least give participants some background in what's going on in this linked data, semantic web world, that they're participating in. They didn't need to have exhaustive understanding of this, but we thought it would be very helpful for them to have a basic understanding of what their descriptions were going to do once they got out there, you know, got out to the web, or got to another area of access. So we started with a Module 1, which we called Introduction to Semantic Web and Linked Data. ^M00:20:15 When you have the slides, you'll be able to hyperlink from the header here, and go right to this BIBFRAME training page, which I encourage everyone to go to it. It's available externally as well as internally. There's some very helpful information there, just if you want to have a passing understanding, if you want to increase your knowledge that you have now, of what's going on, this is a great place to start. Module 2, talked about the BIBFRAME tools that we would be using, particularly the editor, the controlled vocabularies that we access through the linked data service, things like that, and then the third module was in the actual use of the BIBFRAME editor. So the next slide shows you where we started and where we were when the Pilot actually began last June, June of 2015. So the slide on the image on the left shows that initial screenshot that I showed you earlier on. We've gone now to a much more robust profile. All of the profiles we were using in the Pilot listed here, all set up according to RDA instruction. So that's the important part here. Now we've introduced a code into a cataloguing code into the BIBFRAME editor. So when you look at the BIBFRAME editor, you will see, rather than simply formats listed, and generic labels for information that you want to input, RDA vocabulary is explicitly presented, so RDA work, RDA expression, on the-in the editor itself. The instructions in RDA were hyperlinked, so if you're working with a MARC record, okay, let me step back, you're doing MARC cataloguing in RDA, what do you do? Well, you look at the MARC tag, what does this tag mean, you might need to go to the MARC authority format, MARC bibliographic format, to figure that out. Then you have to make a leap to how does that MARC element map to RDA? You're doing a lot of thinking here, and a lot of work, and the BIBFRAME editor, you click on the link, you go right into the RDA tool kit. You can read the instruction, so we've eliminated that intermediate thinking step that MARC brought into the picture. Didn't do it intentionally, it was just a matter of fact, that's the way MARC was, when we used RDA in MARC. So I highlighted here RDA work, RDA expression, subject of the work, creator of the work, to give you an idea of the RDA-ness of the editor and the profiles here. I will say one of the biggest challenges in the Pilot was reconciling the differences in vocabularies between BIBFRAME and RDA. Whereas BIBFRAME vocabulary does not have the concept of an expression, RDA certainly does, and we had to map in the best way possible that we could come up with, a way to reconcile that apparent difference in vocabulary and the guiding principle was that cataloguers in the pilot should not have to do anything differently when applying RDA as a code. Right? We could not introduce any roadblocks there. They had to be able to do their work in RDA, except do it in the BIBFRAME editor. So one of the facts that we kept stressing to participants, even though we asked them to take some semantic web training and linked data training was that once they input a description using the editor, they did not really need to be too concerned about what came out the other end, you know, the Kirk side of the duo. Through some interesting turns of events, it turned out that we actually did look at in the Pilot the participants, we all looked at the output, but I wanted Kirk to talk a little bit about that, because it's certainly something that he knows much more about than I do. This is an example of a record, of a resource that was described in BIBFRAME. >> Kirk: Okay, so just, I'll breeze over this a little bit. Basically there is an ID at the top of one of these little groups, and all of them say underscore, colon, B node, a weird number thing. Those are just saying that that's part of a document. You could have an externally available URL, or URI, they call it, that you can access. Well, in this case, it's not accessible externally, it's actually within the document, but we still want to keep it as a group, so these are all subjects, topics, in this case, because that's the type. We use the BIBFRAME. And you also notice here that if you could actually see this very well, it doesn't have RDA stuff in here now. Now, we just have BIBFRAME. So the actual like encoding format is separate from the cataloguing process. So you use the instructions from RDA, and you get BIBFRAME. We have two examples here, the ones that are larger are ones that we actually could, as I kind of mentioned before with looking up names, we could also look up subjects. So a subject was looked up, it's NID, it has a URI, so that URI is the authority, and then we also have just-it's not human readable, really, I mean it's just a number. So we also have some access points, which is something that BIBFRAME 1.0 used, as well as a label. But access points are kind of a-a construct for an older system, where you didn't actually have a unique identifiable number for something, so you kind of had to identify it by a series of words. So now we're kind of moving away from that, because we already have something that is unique, which is the URI, and then all you need is a human readable label, and that is something that is consistent with how other linked data systems work. The second example we ran into is where using the rules for LCSH, you can construct a heading that may not actually be authorized, essentially. So at the bottom, these ones that are short, just have an authorized access point, that's basically where the cataloguer just typed it in. They looked it up, they typed it in with all the little double dashes, and everything that is in there, it's not really validated. Those all really should have URIs attached to each one of those parts. But in the Pilot, we never actually figured out that particular method, so that is one of the things we're going to be working as our next [inaudible], so that's that. Okay, so that's one lesson learned. >> Paul: Yeah, so now I want to talk about those very same topics from the cataloguing point of view, that maybe more of you in the room might be able to relate to. So this is where the duo had some-we had some disagreements here, you know, it wasn't always rosy. So we had certain constraints in the Pilot, and one of them Beacher mentioned, that we were asking cataloguers to do duplicative work, right? You would do your description in the Voyager ILS, and then you would do it in BIBFRAME. Toward the end of the Pilot, we reversed that order, you could start in BIBFRAME, then go to the ILS, but cataloguers needed to do their work two times, but I think it worked out well, and I think we learned a lot from that. But what cataloguers do, and what technology people think cataloguers do are totally different [laughter]. So a cataloguer, or actually, let's not be biased against technology people, just the average user, the public user, so let's say you go to Google, and you're looking for something. Right? You're going to put in generally a keyword search, something is going to come up, you're going to get results, you go through, you refine your search, maybe, or maybe you find exactly what you want in that first screen. That's what a user does, and I think that's what technology people think cataloguers do. But cataloguers are actually looking for something that they want to be sure exists. We're searching to find duplicate, right? So we have to have a much more targeted search. Keyword searching is great, but for cataloguing purposes, that left anchored search is even more important, because we're looking for the known, not for the unknown. So, for example, I wanted to use a resource that is about to be actually has been published, just this year, it's called linked data for cultural heritage. I showed the MARC record, in fact, Sally McCallum was involved with this. She has a chapter in this resource. I hadn't read it yet, but I'm looking forward to doing that. But I want to just talk about what we did with the names and the subjects here. So we have editors, Ed Jones, and Michelle Sakol [assumed spelling], then we have a really nice array of LCSH subjects assigned for the work. So let's take the adjuncts, I'll give Tim Carlton a break, because I'm always using Tim, so I thought I should get somebody else. Let's talk about Ed Jones, and let's talk about that second-well the first two subjects, linked data, but more importantly, the second one, linked data case studies, with the form subdivision, and talk about what BIBFRAME does with those, with those things. So here is the person lookup that we would use in the BIBFRAME editor. Kirk already told you, this is searching against the name authority file, as it resides, as linked data in id.loc.gov. ^M00:30:03 So a cataloguer at first, when we were starting the Pilot, this was totally relevant ranked keyword searching. That is not going to help a cataloguer who wants to see how many Ed Jones' there are, and if the one he wants, or she wants, is already represented. So now meeting of the minds, we now have a left-anchored search in id.loc.gov, you search in Jones, and you get a great array of possibilities here. Now, one of the advantages of doing your work in the voyager ILS first is that you would already have decided which one of these Ed Jones' you needed, because right now, in the editor, you are not able to retrieve the actual authority record to analyze it. You can only see the 1xx, the heading, and you know, again, technology people will go why is that so important? You just want the identifier, that's all that matters, and certainly that's true in the linked data world, it's all about identifiers, but cataloguers still rely on that text stream, right? So we have to be able to see that. So it searches very well in ID, and it turns out that the Ed Jones we want is the one who was born in 1951, we could click on that. But you might have noticed that there is a second box that says record authorized access point if added to LCNAF, but does not appear in id.loc.gov. Well, why would that happen? Because there is an overnight distribution of authority data from our Voyager in NACO node, the voyager name authority file, into id.loc.gov, if you were cataloguing that resource today. The Ed Jones that you needed had not been established. You would have to establish it in Voyager using our cataloguing client, but the record would not distribute to id.loc.gov until the next day. So we have a way that cataloguers could input the label, the authorized access point that they were creating to hold it in the BIBFRAME database. Now let's talk a little bit about subjects, again, from a cataloguing point of view and not so much from a linked data perspective, although it certainly has an impact on linked data. That second one that I highlighted here at the top is linked data with case studies. Now if we searched subjects, again, looking up against id.loc.gov, we key in linked data, we get a match. It's right there. Linked data. There's nothing in the LCNAF until somebody holds a conference, a linked data conference, right? So we're happy with what we see, because we want a topic, we want a topical heading for this resource. But you don't see case studies there, so what's going on? Why isn't it there? For many years, LCSH has worked on a very pragmatic principle using free-floating subdivisions. So certain topics fit into categories, and under those categories, there can be certain subdivisions that are appropriate to those categories, so you can pick an appropriate subdivision from the list that is appropriate to the heading. And you don't need to create an authority record. This was not always the case with LCSH, at one time there was an actual authority string created for every LCSH heading. Well, always dangerous to say "every," but much more regularly. But the free-floating practice, fewer authorized heading subdivision combinations were being created, but it was an expedient decision because it increased the time of working through production. I mean, things went faster when you didn't have to set up the authorized access point for every heading subdivision combination. In fact, although we saw linked data as an authorized heading in LCSH, there is also a subdivision record for case studies. Those subdivisions have their own authority records as well. But what we had to do in the Pilot was ask cataloguers when applying a heading subdivision combination that conformed to free-floating practice to explicitly put in the heading subdivision combination with the double dashes, the traditional LCSH shorthand, and then that in the BIBFRAME back end would convert to what you saw in an earlier slide that Kirk talked about. But now, I'm going to put Kirk on the spot, because what I never was quite sure about was what happens to this string in BIBFRAME? So does the ID up here represent that string? >> Kirk: So, yes. The ID would represent that string basically, but you kind of see a little bit of a problem, because back when I was trying to explain this before, it's a blank node, and so it's not necessarily something that is easy to find or reuse. So one of the challenges we have like in this case, is this something we're going to, you know, we want to be able to find again somehow? You might have to save it. We might have to change this from blank node to a different construction, where it's like a...something local to our system, but not necessarily something you want to say everyone should use, it's just something that we're using internally because we thought it was a good idea. Because otherwise you're going to have to do this, you know, you're doing it one time is one thing, but what if you're doing it 100 times? You know, what if there was 100 case studies you had to catalogue? Well that would be kind of annoying. So you'd want to do this stuff. So that's one of the things we've been thinking about, in our systems, how do we, you know, make things a little bit easier by looking things up, or choosing from lists, or having defaults, those kinds of things. >> Paul: And so something long-term that definitely the seed could be planted in phase two, but something we might want to look at in the long term is maybe a way to know that one LCSH heading has a certain authorized list of appropriate subdivisions. So I'm not saying that we would have to create an authority record, maybe we would eventually, but wouldn't it be great if you could call up that heading and see, oh, which subdivision is appropriate? Have a list come up, where you could pick from that list, right? So ways that we could sort of use linked data, use the BIBFRAME editor to improve on the way we can describe resources using LCSH when it comes to a heading subdivision. This is a long-term thing, and it's one of those paradigm shifts in the way that we approach. Now, free-floating subdivisions have been around for a long time, and now I'm saying well maybe in the future we might need to think of another way and future could be years, years ahead. But the BIBFRAME pilot phase one brought this to our attention that hey, maybe there is something we can do to make this process a little bit easier for cataloguers. So Kirk talked a little bit about, in a way, that some was still a little bit hard for me to understand, about how he would create these explicit lists of control terms in id.loc.gov so the BIBFRAME editor would look them up. Here're some examples here. But I wanted to ask Kirk to talk a little bit now about the value. You know, as we look more towards linked data sources, external vocabularies, internal vocabularies, what value is there. Is there an increasing value in linking to an internal vocabulary? Where you download an external one internally so you have a little bit more control over it? Or is the value more in linking outside, so we don't have to duplicate the work? And I just wanted to see what Kirk thought about that, from technology standpoint. >> Kirk: I don't think it was one of these three, but one little issue that we kind of run into is trust. If you-in the linked data, you can essentially link to other institutions' data themselves, so you don't necessarily have to keep it internally. So RDA is one example. I mean, these lists that we have are all on RDA's linked data service, and we could theoretically use them. One little issue is that they're not exactly consumable, at least in the past. They're not consumable, the way that we were doing it, in our system, so they're a little technologically behind. It was still usable, but it was just a little bit off. Mostly because they didn't really have a searching, they didn't have an index, they just have the documents. So it's all-you almost have to cache them, to be somewhat inefficient, a second reason we kind of want it internally is because we could use our own infrastructure to do it, then we don't have to worry about what happens over there. There actually was an example where Paul told me about a list, I implemented it, it didn't work because it didn't work. It was actually the RDA list had some errors, and we actually had to correct it ourselves. And I had to tell him about it, you know, so we all make mistakes, we're all new at this. So that's one of the reasons we've actually been like importing data into the id.loc.gov, system. Because that way we are in control of it, we can make sure it works. When someone says something is wrong, we have control over it, we can fix it. But in the future, I think we are going to have, you know, some things are going to be external. We are going to allow people in profiles to say you know what? There is this other term that is useful to my particular format that I'm working on. It's not an ID, but it's from someone we trust, and we'll go ahead and use it. So that is one of the things that will happen. The same thing with our records, I mean, one of the promises is that we'll work on something, we'll have a description for a resource of some kind, and it will be there, then people can just link to it. They don't need to actually do copy cataloguing, essentially, you know, you have to go through and copy every single piece of information or make sure it's valid, you can simply say you know what? It has this number, this URI, and it's that, that's what we're looking for. So we'll hopefully get there, but we're still early, still new at this, and everything is up in the air. The technology is, in some ways, it changes so fast that we can't keep up with it. Other times it's like we're inventing it at the same time we're doing it. Sometimes we find out we're a little bit behind, and we get told by other people in the community that we need to step up our game and stop doing something that we thought was-some other group had told us that was exactly the right way to do it [laughter], so you know, we're all these different directions. ^M00:40:29 So that's-I think we've been doing a lot better, and we have all these relationships with other universities that are working on the linked data for production project, which really is trying to kind of work on these things where, you know, we have things we actually work on to make our systems provide resources for users. So we need to actually make it work, and how do we make it work? Well we need to make production systems. How do we make production systems? Well we have examples of things we need to do, and we implement those. So that's something we're working on the next two years, and I think that's something that is going to push us a lot further, a lot closer to really using linked data for everything. >> Paul: Okay so this is-we're going to share, this is more or less an introduction to Sally's part of the presentation, but we want to talk about our view of the next steps, based on phase one. We want to continue to analyze the data that Beacher mentioned, all the descriptions are out there, we can still look at them. They're in vocabulary 1, but they're useful. We want to address the community review a BIBFRAME, the vocabulary 2.0, which is relatively new. Hasn't been out that long. Except for other control vocabularies, you want to read any of these or should I just read them off? >> Kirk: Go for it. >> Paul: Okay, take lessons learned from phase one [laughter] into account as we work on the profiles, you know, this is our wish list. For how can the editor be improved for the next phase? Refine some of the MARC mappings that we had, and capitalize on the positive achievements, and there were a lot of positive achievements. There were some rough bumps along the road too in phase one, but we're capitalizing on the positive achievements from phase one, as we look toward phase two. So now, Sally McCallum will talk about the visionary future of what needs to be in place before we can even contemplate starting the next phase of the BIBFRAME pilot. ^M00:42:28 [ Applause ] ^M00:42:34 >> Sally: Thank you, and that was an excellent introduction. This is sort of the eight-step program, eight-step project, to get to the next pilot, and it is a huge undertaking. And the first one, the first thing we had to do was work on the model, and how did we want to change the model? How did we want to change the vocabulary for the next pilot, and that is 2.0, in other words, BIBFRAME 2.0. We had a lot of input on 1.0 since 2014. We've had community-wide input on get help, we had something like 200 comments that came in, we reviewed all those. On the listserv, we had more than 200 comments. And somebody sort of distilled all those, to see if there was a whole lot of listserv comments, can maybe yield one really pithy comment, but still, it was important to pick out what we could use. We had some expert advice. We had a consultant or two do some work for us, and review some things, parts of what we were doing. We had the pilot experience. And the things that the additions that were made to those profiles, during the first pilot. Those-what those additions said is those are missing in the vocabulary 1.0. We have Program for Cooperative Cataloguing comments. We had the LD4P comments, and those are-that's the cooperative project between, among rather, Stanford, Harvard, Cornell, Princeton, Columbia, and the Library of Congress. They are funded participants, and we are unfunded participant, but they wanted us in their pilot, in their program. And they gave us a lot of comments. And they're still giving us comments. We had the audiovisual media study that we had, we commissioned, from some audiovisual specialists who worked with the people at Culpeper, on it, and it gave us a new view of an important area that we have incorporated into 2.0, and then we have proposal papers for key areas, for titles, for agents and roles, and there were a number of these. And we put them out and left them out for comment, put them out on the listserv, I'm sorry-put them out on the website, announced them on the listserv, and got comments on them for about three or four months. So the initial model, 1.0, was simple and innovative, we thought. It had works, the key areas, works, instances and annotations for your holdings, for your cover art, for things like that. Very interesting idea. And if you could see the screen, I'm not sure you can, of the Works, you have agents and something else-creators. Creators and subjects, and off of instances, you have things like the publication and the typical things that are related to instances of works. So our 2.0 model is fundamentally the same, but we had a couple of adjustments that make the picture look a little different. We clarified events. And events can be content. So they can be-the works can have content of event. They can also have subject of event, and those are two different-really different concepts to the audiovisual people, and so we tried to incorporate that into the model. We have-we added items as a core class, rather than calling it-using annotations as a substitute for item. Now, the vocabulary. We had a good introduction to the fact that what we call the vocabulary in BIBFRAME is. It's similar to the MARC fields and subfields. MARC vocabulary is 260-input screen said probably 260. BIBFRAME vocabulary are single words and phrases such as provision activity, which is the same as a 260. And, but on the input screen, you can do anything you want . And that is what Kirk and Paul tried to make clear, that we have more control over what we actually use with respect to the cataloguing environment, and the input environment, and we are using that control to make it a better environment than we had before. Not that you didn't all learn what a 260 and 245 and 350 and 300 and so on were. In the vocabulary, we also have rules. We had to decide on. And one-the first one was we decided to continue to use the resource description framework, RDF, for the vocabulary. MARC itself is, well, you have a lot of tags, which is like the vocabulary, you also have an underlying set of rules for how you express that, and that is called ISO2709, it's a standard that just gives the platform for how you do, how you express that vocabulary. And we decided we would go ahead with the W3C resource description framework, because it is sort of the basis for linked data, and it is supported by the World Wide Web Consortia, rather than by just library groups. You can see there are some examples of conventions we adopted, which may or may not mean very much, but the distinction between data type and object type is very important in RDA and RDF. You had to be able to do your label, the text version of something. You also wanted to be able to have the URI at the same time, and we had to make it so that could happen. And various other things that are very...they're aspects or characteristics of RDF. We had to make choices on. And so the holdings annotation became the item core class. Authorities in the new vocabulary became agents and concepts. We don't use the word authority so much, because we use agents, which are the persons, organizations we use [inaudible], and we use concepts which are topics, places, times, events, and works. And then we have better accommodation of standardized vocabulary, we think, and pre-text vocabulary, and real-world objects. The community went very crazy about the distinction between real-world object and the label of a real-world object, a couple of years ago. And it's a valid distinction, whether-and it can be used for various things. It's not tremendously useful, but it can be used to make certain kinds of inferences about things. And so we made it a better distinction between those two. And most of all, we have a better accommodation of RDA. That vocabulary 1.0 was a mixture of MARC and RDA. MARC, AACR and RDA. ^M00:50:09 Whereas the new vocabulary is much more-it's planned, it's organized, within the RDA, organization, like the RDA organization, and it uses a lot of RDA. We did finish that in April. We published the model and the vocabulary, and it is the foundation of everything we do in the pilot. So these things, these steps come one after another, and they are dependent on the earlier steps. The second one is the-the second step is the MARC to BIBFRAME conversion, which is a very difficult task. We did make a commitment in the first pilot, and we've had one in the second pilot, we hope to do it better, to bring forward all of the MARC data, so that cataloguers, when they are trying to create a record in BIBFRAME, can look at the whole body of the catalogue in BIBFRAME, and then decide what they want to do. And because that's the way cataloguers have been working and how they should work. But there are vast differences from MARC. And we had to, first of all, we had to identify patterns in the MARC data. But we have to deal with the things in MARC, because MARC grew over years, over 40 years, and one community wanted this, another community wanted that. They were similar, but they claim they were different, so we do both of them. Things like that have elaborated MARC. There is a variety of approaches, sometimes you have statements, sometimes you have codes, sometimes you have control terms, sometimes you have text. You have all sorts of things in MARC. You have the extent of MARC, which even though we were trying to follow RDA and RDA, the RDA model, to some extent-we have acquisitions, and subjects, and shelving location, and preservation information in MARC, that is not in RDA. So it's not going to-RDA is not going to tell us anything about how to structure the vocabulary or what we need in the vocabulary for those areas. We have a duplication of data, and that is the thing, one of the things that has proliferated over time, is we have codes, and this-we have the same thing in text form. We have the same thing maybe in controlled vocabulary form. We do that a lot in MARC. We did it from the very beginning, let me say, but we did it increasingly as time went on. And we have local data. We have a lot of important local data in MARC that we have to record, we have to be able to show it to cataloguers so that they can understand what they're looking at from a technical, from a cataloguing point of view. We have to identify, we have to have the identification of the URIs while possible. So we may bring a code forward, we want to look up that code in ID then, get a URI for it, and substitute that URI for that code. And as you know, we have a lot of coded data in MARC. Even controlled terms, we want to take the controlled term, we want to look it up in ID, we want to have a URI instead of that term, in our RDF descriptions. We call them descriptions when we talk about RDF, rather than records. Then the various RDF techniques, we have to figure out how we-there are several ways you can usually do something in RDF. We have to decide okay we're going to do it this way, and we're going to do it consistently this way, rather than doing it this way for this data, and that way for that data, and that way for another kind of data. So we want-we are trying to keep things consistent, and we want to eventually make it shareable. The conversion specs are almost finished, and we have a consultant, we have employed a consultant who knows a lot about MARC, and a lot about linked data, who is going to do the-write the actual programs for the conversion. Step three, MARC to BIBFRAME conversion program, we create, we need to create the conversions of the test programs. We need to create a conversion service for the community for experimentation if possible. And that actually seems like a little extra that we shouldn't have to do, but it is very useful and we found it very useful with the 1.0 vocabulary, because the people in the community got right on it, converted records that took this converter, convert records, and try to give us feedback. And that is more than, you know, we can get even from our own cataloguers. We got it from across the country. So it's very, very important. And we want to share those programs that, we always do share, and we always try to share. Step four, preparation of the files. We have to take the-and this is a big, this is a huge project, part of the project, we have to take the MARC title authorities, and they become BIBFRAME works. Work descriptions. We have to take the bib records with uniform titles, match them with these work records, and merge them into the work description. So we have these match and merge, match and merge. We have MARC records with uniform titles, but no authority record, which there are many of those. And we have to create a work. So we have to distinguish between those that have uniform titles, and no authority, and those that have uniform titles and do have an authority, so that we can create a BIBFRAME work record. We have to take MARC bib records that are without uniform titles, and there, we can create a BIBFRAME work description. Then we have to merge the subjects from the BIBFRAME, from the MARC records, into the BIBFRAME work descriptions, and consolidate the subjects. If there is more than one MARC record that goes to one BIBFRAME work record, we have to take the subjects from both of them, merge those in some way, and put them together, and put them on the work record. And then the MARC bibs, we finally-what's left, we have to go, after we've taken all the work information off, we have to split the instances. And that is very difficult, because of the way we've done that in MARC over time, and that we tried to sort of push in different instance types into one record, because it helped with our systems. Our systems worked that way. And so we do have-we want to try to split those off, then, in the new environment. Which is, again, that's RDA, and the way RDA would like for it to see a structure and model bibliographic data for, they think, a better user experience. And while we're doing this, we want to keep pointers among the new work and instance records and descriptions so that these things don't fragment. Step five. We've got to prepare the-we've had to prepare the infrastructure, and that's been ongoing since, oh, last year actually. We use the-and this is the hard core platform, this is what Nate Trail, in our office, is a person who handles this the most. That's his focus, let's say. The LC uses the MARC object platform. We've had a major move of the platform internally to virtual servers. Now, we have accomplished that with difficulty, but with very good assistance from OCIO, from the newly reorganized OCIO. We have had a major version upgrade of the platform, with the addition of a new semantic module. We have done that. We've got that in place, but we have not got all the data loaded to it. Because we need to have lots less movement, then, of all the data that we have in the old version, and the old linked data service into the new linked data service, without interruption. And this is not-I mean, while the pilot uses ID, the linked data service, the community uses it a lot. There are peak times when there are several million hits a day on that service, and other times when it's more like two or three hundred thousand. But it's always very intensely used. People have gotten-they-the linked data service has been in operation for one vocabulary, then two, and three, four, five, for the last six years, because it came up in 2010. And so a lot of people, a lot of systems people out there have started using it to update their systems, to get information, to get current information from us. So we-and when it goes down, they let us know [laughter]. So we have to do that without interruption, and then we have to plan and load the new, revise the re-converted BIBFRAME files, in this new semantic environment. And we had a different kind of semantic environment before. Step six, we have to revise the BIBFRAME editor and the BIBFRAME profile editor. And you've heard a lot about that this morning, more than what I would be ready to say, review and revise editor functionality, and revise the interface labels. I think they told you, Paul, I think, told you about how the labels were designed for the interface, and he has, I'm sure, ideas on how he wants to redesign or revise those labels. ^M01:00:13 Based on what his interactions with the cataloguers, in the pilot-we have a lot to do, and we have to make this available to the community. We have to rebuild the links between the editor and the actual vocabulary. Step seven, review and augment the linked data service. It's an integral part of the pilot, so we want the editor-it provides the editor with its drop downs, with its look ahead information, with all sorts of things, and while I've talked earlier about the outward use of it, it's also a very heavy inward use of it, for the BIBFRAME, and for the pilot. It provides the URIs for the data, during our preparation stage, when we're preparing the files. We need to redesign this application, move it to MarkLogic, and augment it. And finally, step eight. A very big one. It was excellently done for the first pilot, and that's the work that COIN does for preparing the materials, training material, holding retraining sessions, holding new training sessions. They had an excellent-did an excellent job of setting up feedback mechanisms, so that-and giving cataloguers constant support, so that I think it was every week or every couple of weeks, they had a session that you can come if you're having trouble, come, if you don't have trouble, you can just continue to work that day. So they did a lot of work to prepare the documentation and to hold training, and to hold the hands of the people during the pilot. So part of-we're starting a wish list for the new pilot. I think a few, Kirk and Paul, made a few comments on that. We would like to have daily conversion of the BIBFRAME, to BIBFRAME, and load of the new bib descriptions, with the first pilot we could not have daily load of bib records. We had daily load of authority records that were coming into the ILS, and then coming into BIBFRAME, but not bib records. There is a major undertaking, major challenge, to be able to do that. Because you've got to do this merge and match when you bring any one record into this set of records that is already there. And we would like to have an input editor for names, and for subjects, so that people could have an experience of what it's like to try to do their names, and their subjects, authorities essentially. I've used that word, but I'm not supposed to. But at any rate, those descriptions, in the right-in the environment they're doing their Bib record in. So take away from this, what I said, Keystone is the vocabulary. We're having some trouble with that, but if the vocabulary keeps changing, then we have to keep changing all these things, all the way up, including the documentation for the training. And all other caches are dependent on it, therefore on its stability. But we see the pilots as essential for understanding what we're going into for the migration of MARC to the new platform, which we've done a lot of work trying to make that as good as possible, because we have 50, 100 years of cataloging information that we can't lose and we must be able to bring it forward. And it also, we see this as part of understanding, how we make libraries a part of the linked data environment. So thank you. ^M01:04:04 [ Applause ] ^M01:04:10 >> Beacher: Now we are open for questions to any and all of us. We'll just start [inaudible]. ^M01:04:21 >> Is the intention to be able to save the records this time, so that it can be used to [inaudible] be there, like in the first pilot, and not be able [inaudible]? >> Well all need to stand up? >> Yes. >> Well someone who is going to answer. >> I think a better thing to think of, actually, is that the editor was just an input screen initially. It doesn't do anything. And so is that useful for production? Well no. Because you need to do things like you're mentioning. So then what do you need for that? You need a bunch of things behind the scenes, to make it all work. And so that's what Sally was talking about. It's part of getting all the stuff behind the scenes working. We're going to have whatever the editor is called in 2.0, I'm leaning toward renaming it something completely, because it's going to be really a part of a prototype ILS like system, rather than just simply an editor where you can just type things in fields. So it will have saving, and we're really hopeful we'll have a lot more features, not just entering descriptions. Like Paul said, we've always had this hope that you can do a lot more things, like authority work. And so that's another thing I think we don't want to do. So you could actually go into an ID record, for a name, actually open it up, and maybe make a change to it and save it back into ID, into our system. I think that's one thing we'd also like to do, because I think that's, and then that would somehow flow into the Voyager system, somehow. I mean that would be like years in the future, we might actually do that. But that's one of the ideas. >> Jada? >> Beacher: I'm supposed to come up here because we are being filmed. Regina? [Laughter] ^M01:06:09 [ Inaudible Comments ] ^M01:06:12 >> Given that RDA can be output as RDF, given that there were [inaudible] and company, have developed [inaudible], a demo editor for outputting RDA as RDF, or they say as [inaudible]. What-why isn't or is LC investigating going in those directions as opposed to working on its own to sort of parallel some of these efforts? >> Beacher: Well I don't-I think as several of us have said, we are collaborating and working with various constituents in the community, and we are, and have been, working with Deborah Fritz, and company, and I'm on the RDA Board, and the RDA Board has, I think it's fair to say, adopted [inaudible] as one of the paths it wants to take. I know Paul and Judith in particular have worked with Deborah and several of the ALA Meetings, to see how these come together, and it was also part of what we discussed at the OpCo meeting in May. Paul or Judith, do you have further elaboration on that? Or even Sally or Kirk, beyond the fact that we are taking those into account? >> I think it's a good question. It's a valid question. But from my perspective, we're still so new at this, that there needs to be a lot of experimentation still among different constituents before we all come together and agree on something. We have used Deborah's product, the RIMMF, and I think we had a very productive demonstration of how that could be used to display visualize RDA, and then we use the BIBFRAME editor. That's the type of experimentation that I still think needs to take place before we actually, you know, buckle down and say this is the way we're going to go. >> One of the things that I think LD4P is really focusing on is partnering with each other, working with each other on strengths and weaknesses. The RIMMF editor is as far as I know a Visual BASIC doc type which is not very popular in the library community. It's closed source. It's not open source. These are about open source. It's the opposite, where it's not accessible by anyone, certainly you could use it, like they have a license, where you can actually use the tool, but you can't make any changes to it, as far as I know. And so it becomes kind of difficult while it's a great-I mean, it's been great for the community, and people like it, but how can I integrate it into our MarkLogic system? Well, it's not possible, because it's in Visual BASIC, and that's not one of the options. And so certainly we could port it to something else, but that would be a really large effort to do that, and you know, essentially that's what we're doing. So I am kind of disappointed that's one of the cases with that particular tool, that it seems like we don't really have them, you know, we don't have that in our development community where, as far as I know, none of the LD4P partners are thinking about RIMMF for, you know, porting it or working with them at all. So that makes it difficult. As far as the vocabulary, I know one thing that has come up before, and I think conversations, Sally might hopefully be able to agree with me is that people consider RDA's version of RDF is too complicated. It's like-there's obviously a need for complicated vocabularies, because the world is complex. ^M01:10:04 So you need to have things. But at the same time, if you look on Google, what happens on the screen? Well, you know, you get a list of gobbledy goop, you know, it's just a bunch of words. And certainly it seems behind the scenes it does all sorts of great things with their keyword searches, but it's really, actually relatively simple, like the amount of stuff they have. And one that they've, you know, ontology really prefer is, is [inaudible] which is a lot flatter than BIBFRAME. It doesn't have a lot of classes, but has lots of properties. And even those properties, there's lots of possibilities, but I think we were investigating some of the implementations of that for library materials, and it was like 8 or 10 properties. So it's pretty simple. If you look at something like, you know Dublin core is used by DPLA, and Europeana, they have about 20, 21 properties. I think I was telling Sally about that the other day. So they're-they've dealt with the complexity by making it less complex, but because of that, it doesn't accept the range of descriptions that a lot of times different library communities want because they really do want to be able to describe things in a lot of detail, and it could be difficult to do that if you only have 21 property options. Of which about five or six I think are just for the system. So. You know, that's one of the things I think is a challenge. It's that is Google going to adopt RDA? I don't think they even understand it or know about it [laughter], and so, I know that's something I worry about with BIBFRAME. Because BIBFRAME is still complex, but I think we at least-our goal is to-we want to be able to hook into these other things that are maybe not as complex, but we have some, you know, we're thinking about same as relationships, where you can say it's the same as. So if you're searching in one of those ontologies, at least you can get some BIBFRAME, and maybe as they get more BIBFRAME, it becomes more useful and they see it's there. And if we have a big volume of it, it's going to be useful to Google, and they're going to use some of it, so that's one of the goals. So it's a challenge. I mean, not everything works in technology. Maybe people succeed. Maybe RDA is better than what, I mean, we're all doing experimentation. We are not quite there, but that's one of the things I think about. So, good question. >> That's very helpful. >> Aaron? >> How is it with let's say, distinguishing between let's say baseball, in Australia, with Cricket, in the United States, you know, the [inaudible]? Keyword searching, you don't have the link between the subfield D and the subfield A, you would not be able to distinguish that record from baseball in the United States with cricket in Australia, but [inaudible] works. The examples you show for subjects don't seem to have the ability to break down fields, eliminate subfields. Is there a commitment to preserve the pre-coordination [inaudible]? I know RDA seems to be wanting to make sure [inaudible] will accommodate RDA. Is there a similar commitment to preserve LCSH and BIBFRAME? >> Well, definitely during phase one, and most likely phase two, as I said, cataloguers had to do everything that they do now in MARC, in BIBFRAME, and the Library of Congress has made a commitment to continue to pre-coordinate LCSH strings, so that's why we were doing that. The point I was trying to make is that what happens when that pre-coordinated string is not matched by something that can retrieve it again sometimes? So yes, we definitely are continuing LCSH as we're instructed to do now in BIBFRAME, and I know that will continue into the next pilot. >> Beacher: Peter? >> Peter: I have a question about, okay, is the editor going to come in a new ILS, for instance, [inaudible]? Because I know that [inaudible] will no longer be supported [inaudible]- >> That's not true. >> Oh it's not? Oh, okay [laughter], so I'm still questioning what is coming for the next generation of ILS's and different it is. >> Well, I'm probably the last person who should answer that question, but I will say, I'll confirm what Anne said, Voyager is supported, and right now, we're not looking at BIBFRAME as a database of entry, I mean, that's coming down the road. Maybe you all could add some comments to that? >> Beacher: No, I think that's not one that we will answer, and Anne said it succinctly, she has responsibility for that, and she will be keeping all of us apprised of her...foray into replacement system for Voyager, but now Voyager is Voyager, and BIBFRAME, we will overlay on the system that we have. Questions in the back? Since I have been starting at the front? Any remaining questions? If not, I know Judith has a statement she wants to make, Sally is there anything else you need to say? And my other colleagues? Okay. Judith? >> Judith: I just want you all to know that I have Beacher's permission to put on a series of sessions, probably in the dining room, I will find out when I can get the dining rooms, and they will be an opportunity for people that were not in the pilot to have a closer look at the editor. It won't be hands on. I'll be calling on Les, and Hien and Tim, and Manon, to provide this training. But I am curious, how many of you would be interested in taking a closer look at the editor, and what people that are in the pilot are seeing and doing? Because I know today it was very difficult for you to see the screens, but there wasn't much we could do because it was being filmed, and they need the light. So is it-what's the level of interest? Oh good, well I'll start with a couple of sessions. If I need more, I'll put on more. They'll probably last a couple of hours, but it will give you an opportunity to have a really good look at the editor, and see how it's filled in by those that are working on the pilot. And when we finish phase 2, I'll do the same for you, so that you can all keep current. Alright. Yes? >> Could you be sure to include Culpeper in that initiative? >> Okie dokey, we'll do that [laughter]. Yes. Sorry. >> Beacher: You can tell by her face, you'll have to figure out how she's going to do that [laughter]. >> Yes? >> I have a question for, uh, Kirk and Paul. Did I get the name right? >> Yeah. >> And this must have been with the authority creation, you said that there is a delay with using the different editor in order to get a name that had not been established, then you can establish it, and then it gets uploaded. But in the future, we're always going to be referring to ID for doing all of our creation of authority work, will there always be that delay? Is there some way to make it more seamless? Is that something you're thinking about? Is that something that has come up? >> Kirk: Judith told me I have to repeat the question. I know the answer, but I'm trying to think of what the question was. So that basically [laughter], you have to basically think about, you know, obviously we're doing things in MARC or Voyager, then we're porting it over to ID, and then there is a delay, because it takes a day or something, whereas we could just simply enter it in ID and be there. And then it would go to Voyager, and probably could also be a little bit more seamless. So yeah, I mean, I think that's definitely one of the things you want to do because, you know, especially with names, I think that's one of the things we really could accomplish, but you know, it takes some more effort because it's kind of-uh, again, I might be overstepping my bounds, but I feel like it's kind of stepping from experimental to production, when we're you know, I don't want to get yelled at, about stepping into Voyager's domain, but basically that's what would happen. We'd have to really push it into their court, as something else, and that's another thing they'd have to work on and maybe they're not staffed for that right now, so you know, but we've got to-I think that's one of the things we have to think about as part of this pilot. It is that once we experiment with names, maybe we can, you know, in one of our test databases, we could actually enter things immediately and then figure out how to generate, you know, MARC, basically at the same time at that point, as maybe we can change our processes. So it's a little bit more efficient. And I think we can do more with our linked data service than we can with the MARC authority. So maybe there are actually some enhancements we can put there, to make it a little bit easier to use. So there is a lot of promise there. That's one of the things I hope we get a lot of good information when we work on that, our next pilot. >> Beacher: Paul, did you want to comment? >> Paul: Well, I can't resist the opportunity. Okay, so when Aaron asked his question, I had to say that, you know, we're making, we're saying that cataloguers should not have to do anything differently. So I'm just going to say something. Think of a future, possibly where maybe you don't use just the name authority file from LC, maybe you link to another authority file? And then in another country, another-something like that. That's what linked data is all about. So that's where we're thinking ahead, where we might-where there might be possibilities to change the way we do things now, so I just had to put that out there. >> Beacher: Mira? >> Mira: I just wanted to know when do you anticipate the next phase to begin? >> Beacher: Yes, that's what I was going to wrap up with. ^M01:20:05 I was amazed no one had [laughter] raised that yet. As you heard from me earlier in giving you the recap, I'm always pressing to go faster, faster, more and more. My colleagues, and I think Sally laid out a very strong and clear path to getting to the next pilot. I wanted to start in the first quarter of the new fiscal year. I think based on what you heard today, it's fair to say, we will not have the next pilot begin before January 2017. I want the technical side to have the time to do the things that they need to do, so that the next pilot is not as rushed and frantic as the first one, and that there is more confidence in the stability of both the vocabulary and the infrastructure that will support that. So as of today, I think it's fair to say that we're aiming for the second quarter of fiscal 2017, meaning not before January. In the interim, then, we'll be having these sessions as we are having, similar to today, and the ones that Judith just described in terms of giving those of you who are not necessarily involved in the pilot now a better sense of what the tool is like, and what is involved in getting ready for the pilot. Do I have any objections from my colleagues on the front row [laughter], alright. They set the stage for this at ALA Annual, when I had been saying the first quarter, then by the time I got up to make a presentation, I had to say, well, I'm being pushed back, and I think this really does make sense in terms of the complexity of what we want to do, and that this is really going to be a transformative initiative, not just for our area, but for the Library of Congress itself, and the community with which we are working. On that note, are there any final questions or points to be raised? We have about three minutes. If not, then we will close with that, and I thank you for your participation and my colleagues for the work they're doing [applause begins] to make this happen [applause continues]. >> This has been a presentation of the Library of Congress. Visit us at loc.gov.