>> From the Library of Congress in Washington, D.C. [ Silence ] >>Beacher Wiggins: Well, good morning. I'm Beacher Wiggins. I'm Director for Acquisitions and Bibliographic Access at the Library of Congress, and today is another session in Library Services LC's Digital Future and You that we present, we try maybe once a month during the year. I'm particularly excited about this one because this is another in a session related to BIBFRAME, the format that we expect to replace MARC in the future. And you notice I didn't put a date on that. Depending on whom you talk to, that could be two years, five years, but definitely is going to lead us into the linked data world. I'm also excited because we have worked hard to present one today that gives BIBFRAME at a more practical level so that you can understand how it might impact the work that you do, impact the cataloging data that the Library of Congress produces and shares with the world. So we have two staff members from within Library Services that will set the stage for you and I'm excited to hear what they have to say for you. This also sets the stage for getting us involved in BIBFRAME in a more practical way. Some of you may have heard that we want to mount a pilot so that we can begin testing the use of BIBFRAME to encompass the cataloging data that we create. So we began meeting with the appropriate folk within Library Services and beyond to get a pilot set up. The pilot is likely not to occur until the third quarter fiscal 2015, which we are about to enter shortly. In the interim, we'll be working on documentation, training, so that we can have the same kind of support that we had with the RDA implementation. Some of you remember Resource Description and Access. So what we'd be looking at is to have a core group of cataloging staff within ABA Acquisitions and Bibliographic Access and some of our colleagues at the Culpeper site who deal with audiovisual and moving image materials, to work on using BIBFRAME to encapsulate the cataloging data that they create. And this will likely mean that we'll have cataloging data created in BIBFRAME and cataloging data created in MARC so that we begin testing practical implementations. We also can answer some of the questions related to how it works in the real world. If you've been following the BIBFRAME website, you know that there are lots of - I won't say lots - there are implementations and testers and testing going on by various institutions. And obviously the Library of Congress as a leader in this effort needs to be in the mix. So we'll have - use the remaining time to develop what it takes to make this transition. We have two, well, one, I need to thank Andrea Kinney, who is Chief of the African, Latin American, and Western European Division. And Judith Cannan, who is Chief of the Cooperative and Instructional Programs Division, who coordinated this series. And Judith in particular has been working with this one because she has a passion now for BIBFRAME, if you can imagine someone having a passion for a technical application. So I appreciate the work that she and the presenters have done, and the presenters today are Kevin Ford, who is Digital Coordinator within the Network Development and MARC Standards Office, and Paul Frank, who is a Cooperative Cataloging Specialist within the Cooperative and Instructional Programs Division. And I think that you will have a better understanding at the end of this session as to how this might work. So stay tuned for continuing information on the rollout of BIBFRAME, the testing, and the work that the Library will be doing in collaboration with external partners to make BIBFRAME a reality. So with that, I turn it over to our esteemed presenters today, Paul Frank and Kevin Ford, and Kevin seems to be moving so you will be the kick-off. Kevin Ford. >>Kevin Ford: Okay. Good morning everybody. My name is Kevin Ford. I work in the Network Development and MARC Standards Office and we're delighted to have this opportunity. Paul will talk a little bit more about the tools that we've developed with respect to the BIBFRAME initiative and demo the editors, in particular. I will spend most of my time talking about what the BIBFRAME initiative is and try to contextualize it within the broader scope of what we're doing here. So with no further ado, what is it, in one sentence? The Bibliographic Framework Initiative will reimagine and implement a bibliographic environment for a post-MARC network world. And like I said, what I will spend probably the better part of the next 35-40 minutes doing is unpacking this exceptionally loaded sentence right here. It has - the Initiative has been going on for several years now. It was formally announced in 2011, when the Library of Congress said we were going to do this. And we published a very general high-level plan of what we expect to do with it. In 2012, we contracted with Zepheira, LLC, to evaluate related initiatives in the bibliographic world and new data models and also to do some data modeling for us. They did this work. They completed it in the Fall of 2012. And at that same time, we published a high-level model and early experimentation began at that time. In 2013, January in fact, at ALA, we published BIBFRAME.org. It's still active. It's where you can find the vocabulary and links to related material. In addition to a draft vocabulary at BIBFRAME.org, you'll find a "Links to Transformation" code. You'll find the tools, such as a demonstration of BIBFRAME Editor. You will find a comparison service so that you can see a MARC record today compared with a BIBFRAME resource that has been run through the transformation in fact. And, if you have a sample of MARC data in MARC.xml format, you can actually upload that data and see what it would look like yourself, so if you've got a particular set that would take a look at. In 2014, in January specifically, we more or less froze the vocabulary. We call it 1.0. And we did this in order to foster and create a stable environment for implementers, for early experimenters, for experimental implementations for work to happen. In the spring of this year, we published the BIBFRAME editor. It is a tool that Paul will demonstrate and it is actually designed in such a way as to be pluggable in other environments as well. One of the things that we're doing is we're trying to create tools that surround, that cover all the things that we need, but stop in a modular way such that we aren't actually developing an end-to-end system per se right now, but we are developing the tools that would help people link them together and make useful implementations themselves. Since the beginning, we've had a number of close partners and participants in the BIBFRAME initiative. These organizations are listed here, OCLC, the German national Library, were part of the early experimenters group. NLM, Colorado College, the Cornell University Library, Stanford, George Washington, the British Library, and Princeton University library. And we continue to have people come on board and start helping out. Most recently, Terry Reese, who is in - who creates and manages and maintains MarcEdit, which a number of you may know, has just some recently integrated some BIBFRAME tools with the MarcEdit. Although the BIBFRAME initiative was announced in 2011, it was a long time coming. And no one, two, or possibly three things on this list could have happened and it be enough for us to hit a tipping point. But there are key elements in the history of bibliographic data and representation that all came together for us to find ourselves at this point. One of the bigger ones is, of course, in 1998, the Functional Requirement for Bibliographic Records was published. The Functional Requirements for Bibliographic Records is a conceptual model. It's the conceptual model that identified things such as works and expressions and manifestations and items, as well as Group 2 and 3 entities, such as persons and organizations. And it was only a conceptual model. It was a way - it was an intellectual exercise on how you could model bibliographic data. In 2002, a very - not a very big article, but ended up being having a popular article was published called MARC Must Die. And in that article, published by Roy Tennant from OCLC, he outlined a number a very important ways that the MARC-related bibliographic format was no longer a good fit in the current technological environment that we all find ourselves in, not just libraries, but even outside of libraries. But one of the big things that happened is this article became titled MARC Must Die. And one of the reasons I include it on this list is because it became a meme especially in the developer community within libraries. It gets emblazoned on T-shirts. Their entire website's called MARC Must Die. And not because there is a complete and utter lack of respect for MARC and its history and all that it's done for us and for the library community more broadly, but because it's just a sign of greater recognition that we must move away from the MARC format in order to gain the benefits from modern computing. From 2005 to 2009, Resource Description and Access was developed and arguably it's still being developed. It could be 2005 to "question MARC." The - this is important because the Resource Description and Access provided a set of cataloging instructions that provided a practical implementation of FRBR. So if FRBR was a conceptual model, an intellectual exercise on how to do bibliographic data, RDA came along and said this is how you can code all of these different things, these works, these expressions, these manifestations, and these items. During the time that RDA was being developed, the Library of Congress formed a working group and this report came out in 2008. It was a very - was a sizable report. It was an important report, not only because of the number of staff and the individuals from this institution that were part of that project, but also because of the very smart and well known minds from outside this institution who also partook in this project. And although a good many things came out of this report, one of the two bigger ones was, one, Sunset MARC and, two, Embrace the Web. Beginning in 2008 and continuing even today, library-linked data services started to come online. We'll spend a couple slides talking about this. What's important about that aspect is one of the things these library-linked data services started with was authority data, and authority data being published as linked data became this foundational for us moving on to describing bibliographic data in a more contemporary way. And finally, in 2011, the Library of Congress, along with NLM and National Agricultural Library, completed the RDA test and decided we would implement RDA. And it was at that point, after all of these had happened, that we hit a tipping point and moved on. And like I said, a lot of this - all of these things had to happen more or less in this order and for us to hit that tipping point to take one simple example, RDA and Description and Access provided the new cataloging instructions and a practical implementation for FRBR, it's hard to develop a container format, a bibliographic format, for that data if the standard is only being developed at the time. So about these linked data services that started to come online around 2008. One of the earliest one was VIAF. Now, it came online around 2007. What's important to note about that is when VIAF came online and it had a web presence, it actually wasn't linked data yet. They didn't create stable identifiers for the name, so they hadn't committed to creating stable identifiers for the names, and they hadn't embraced linked data principles with respect to the publication of data. And what I mean by that is linked data provides a number of technological method that help with the publication and dissemination of data in a very standard way that not just libraries, members of the library community can understand, but a much, much broader community can understand and make our data more reusable in those communities, but also of course still within our own community. When it did come online, VIAF, the Virtual International Authority File from OCLC, published URIs for people. They would later add organizations and places to that, but suddenly we had these stable identifiers that were web-accessible for people. In 2009, the Library of Congress linked data service was launched, more commonly known as id.loc.gov. That's in fact run out of our office-it came online in 2009 with the Library of Congress subject headings. So for the first time, subject headings had stable unambiguous HTTP web addressable identifiers. Since 2009, we've added the entire name authority files select classes from the classification schedule, the thesaurus of graphic materials photographic thesaurus, and a good many other smaller value lists and vocabularies that we manage here at LC. In 2011, the British Library came online with a linked data set and one of the big things about this, about this occurrence was the fact that for the first time, or one of the earliest instances of a large-scale library putting out a large amount of bibliographic data as linked data. So if VIAF put out URIs and put out linked data for people and places and organizations, and id.loc.gov came along and put out HTTP URIs and identifiers and made linked data for subjects and topics and temporal concepts, the British Library came along and put out bibliographic data for the first time. And so we started being able to see what bibliographic data might look like using those identifiers created by VIAF and created by id.loc.gov. In 2011-2012, the Germans came online and published their authority data as linked data. They created URIs for people and organizations and places. In that same time period, this French National Library also created a linked data service and published URI's for people and organizations in places. In one of the things of the French did was the added works to it. They created work resources and making them, again, these URIs and were able to identify works. So suddenly you could look up a work for Les Mis. That was new. If the British Library came out and did bibliographic data and they mostly did, focused on manifestations, the French started to separate those things out and say, no, this is the work, these manifestations, these expressions are over here. Lest anyone think that only the big national libraries and organizations have been involved with it, there are good number many more smaller organizations in the library world doing linked data and publishing linked data. So AGROVOC from the Agricultural Organization in Rome, the National Diet Library in Japan, Europeana, the National Agricultural Library, the Getty vocabularies are starting to come out as linked data. And, again, one of the reasons this is so fundamental is because the focus on all of these projects has been authority data. It has been those names and those topics and those subjects that form the foundation for bibliographic description. Which brings us to the element that we are now focused on, the bibliographic description. So what is BIBFRAME all about? It's not just recognizing that we are in a network world, but fully embracing that fact. It's about not just being on the web, but being of the web. And so libraries have - libraries have done a decent job communicated technologically with each other. We have been moving electronic records around for a good long time. Often, the bulk of those transfers tend to be between larger institutions versus smaller libraries, one, and, two, the nature of those transfers tend to be in bulk. They tend to be large data exchanges versus smaller data exchanges. But also at the end of the day, there's just - we should be doing it a little bit more. We need to be communicating with each other, linking with each other. One library might have one component of something and another library might have another component and we need to start to find a way to link these things together to help the user not just discover the one in Library A but the second one in Library B. And so we need, like I said, we need to start talking a little bit more amongst ourselves. We also need to recognize that we live in a much, much bigger world. We live in a world with Facebooks and Yahoo!s and Googles and Bings out there. And what we need to do is not just talk amongst ourselves better, but we need to start communicating or formatting our data in such a way that we can be visible and seen by these other large organizations, such as the Facebooks and the Yahoo!s and the Bings and the Googles. This is fundamental because so many of our users are beginning their search from this places. So many of our users are already spending so much time in this places that it behooves us to get ourselves into those places better. Which brings me to the second point of what this is all about and that's getting our resources in the hands of our patrons. We want the search engines to work to our advantage. This is a screenshot of a Google search result hit for the book Predictably Irrational. This is what most people will see they do a search for this book somewhere in the top three or four or five hits. But what's important to note is some of the details that come out with respect to this one search hit. So Google can tell you with store location found that, in this case it's Barnes & Noble. Google can also tell you the price of this item or the range of prices that this item is offered for in that particular store location. Of course, Google can extract the description from somewhere and it can even tell you what the reading and for this book, either because of its - because it was rated on its own system or because it was able to capture this information from the Barnes & Noble website, and that's how it's doing this. When Google crawls the Barnes & Noble website, it is capable of looking at the technological layer, at the code that sits underneath the page that you and I can see and read, and extract important information from that. See you and I can go to the page and very quickly identify, oh, that's the author because it might say author and we might already know the author. We can immediately recognize the price of it. We automatically know that is something begins with a dollar sign followed by one or two digits followed by a period followed by another couple of digits, we automatically recognize and inherently compute that is in fact a price. We can identify the description and we can identify the ratings quite simply. But computers, the Google crawler in particular, same with the Yahoo! and the Bing ones, those are no different, often need help understanding this information. They can crawl the page and they can extract all the data from it, but one of the things that Barnes & Noble has done underneath the hood, in the code of the page at Google sees, is say this is the description, this is the rating, this is the price. And Google is able to take that information and do something with it, such as show you inside search results that is available from Barnes & Noble, it's available for these prices, and here's the rating for it. And so we want to get ourselves, position ourselves, so that Google can take advantage of our information. So this is a completely mocked up Google search result hit. This is not an actual hit. I took this and modified it to make a point, so it is fictitious, but it does capture and aspiration that we, that we, that we are shooting for here. Again, and so what we want to do is be able to describe our data at a technological level in such a way that when Google crawls our website, it can extract meaningful information from it and then do something with it and help the user before they get in through our door, you know, before they're even to our website. And so Google can tell the searcher just got this hit where it's located, such as the D.C. Public Library. Possibly even tell you the special location, that it's available in the Southeast branch, the Northeast branch, the MLK branch. Could possibly go even further and say, hey, here's the call number so the searcher can walk right through the door and just find it right on the shelf. Of course, the description is still available for it. This is, again, essential because, again, so many of our users are beginning their searches at Google that it behooves us to get our data into the hands of those who, those users who are spending so much time with from the get-go. We also have a wonderful opportunity now to reimagine and rethink our entire bibliographic environment and the technological systems that go into it and how can we simplify and streamline while also realizing all the gains. And so we need to simplify our data management exchange mechanism, not just for ourselves but also for our users. This has been on extremely simplified view of our current ecosystem. Is not meant to go into great detail, but it's meant to demonstrate the layer of services that sit on top of things. So of course we have an ILS database. There'll always be some kind of database or store on the back end. There's an OPAC layer where the searcher does a - where the user does a search for a book or some other item. The searcher can use that interface. It's not overly problematic for the user, but it could be a lot easier for the user. There are OPACs that tend to require lots and lots of clicking, for starters, and without getting into the technical details, that has a lot to do with the fact that we do a lot of things based on string matching and, for instance, using identifies. So it's very hard to get the user from Point A to Point B without going through an intermediary step, and that's where all the clicking has come from. More basically, our websites could be just designed - our OPACs could be designed a little bit smaller and a little bit better to help the user, especially with respect to the display of information. Machines, on the other hand, when they encounter our websites, and when they encounter our websites they are not looking at the mostly intelligible graphical page that you and I see. They're looking at the code. And the moment you look underneath the covers of our webpages and our OPACs, it's messy. It's very messy. Is not pretty, and machines can't make sense of it. They just got a bunch of gobbley-goop out of it. We don't identify titles and authors very well, so it's very hard for them extract meaningful information from our webpages. Developers have to often go to separate points. Popular for a very good long time now has been Z39.50. It's often times a sidecar service that has an entirely separate access point for developers and making use that Z39.50 service in order to perform searches against the database and extract MARC records from it. Is old enough that it's actually not HTTP so it doesn't operate on the same protocol as your web browser does. It works on an entirely separate protocol. The only reason that's meaningful is because at this point, the only primary user of Z39.50 are libraries. In the interest of making our data more accessible to those beyond our libraries, we need to start thinking about this. That said, we developed SRU, which stands for Search and Retrieval via URL. It is in fact an HTTP service so it will run with the same protocol your browser uses and it was in fact developed to address just that limitation with Z39.50. But even that often times has a slightly different access point for the developer. And finally, the cataloger works with an interface. It gets its own special line here because one must bear in mind that those interfaces, those cataloger interfaces, are desktop applications often. They're not based on your web browser. They're a special application that is loaded onto your desktop and up to 400 desktops depending on the organization that has to be maintained, carefully maintained, and kept in sync, which would require some overhead. But by taking this opportunity, we have the ability right now to start rethinking some of these things. Like I mentioned, there will always be a store, but then perhaps there's just one web layer. The web layer is done in such a way that the code underneath the hood is smartly identified so that when a machine goes to those webpages, it can make sense out of it. The patron, of course, is still understands it. There could be a layer of technological services integrated into this one point for the developer. And finally the cataloger. Cataloging would move to the web layer, too, and we would stop relying on desktop applications and put more emphasis on the browser, a couple of which are on all of our machines. BIBFRAME is also very much about implementing a new data model and rules. So FRBR, with the notion of works, expressions, manifestations, and items, and RDA: Resource Description and Access. This is important in order to reduce our dependency on string-based description and can also, by relying more on links and identifiers in our data, help to manage our ever-growing body of knowledge. And that brings us a lot to this one test great here, which is replacing MARC. This is a MARC record. This is how the machine sees the MARC record. And there are machines that can understand this, but they are almost all in the library space. Machines, programs, software outside of the library space generally have no idea what to do with this. And that's for good reason, but it inhibits our ability to be seen as visibly as we would like to be. And what I mean by, well, that said, is not hard to apply a little bit of formatting to that record and make it more intelligible, but one of the things that you'll see immediately from doing that are all the strings in our records. So what I mean by string, of course, is the fact that you see words, such as notes by Uwe Kraemer, Philadelphia Orchestra, symphonies, James Levine. You don't see anything that looks like an identifier, like an LCCN or some other opaque alphanumeric string. You see the strings themselves. The reason this is so vital to think about is largely for maintenance purposes. So the current system right now, if, let's see, this has Gustav Mahler's name in it, who was born in 1860 and died in 1911, let's imagine hypothetically that someone discovered that in fact Gustav Mahler was not born in 1860 but he was in fact born in 1859. Well, the way our systems are built now, we would correct the name authority record, but then we would then have to go into our bibliographic systems and search all the records that might have this existing string in it, with 1860-1911, and alter it to 1859-1911. Don't get me wrong, there are a number of library systems that have been developed to mitigate that issue and make it as programmatic and as painless as possible, but it's still a tremendous overhead, whereas if we could use an identifier in that place, that type of maintenance becomes a much, much simpler thing. You change the underlying name authority record and that change will then be visible everywhere Gustav Mahler's name appears because instead of embedding the string in our records, we've embedded the identifier that is used to call back the string. Moving on to all these strings. And replacing them with identifiers, you'll see from this record there's loads of strings in here. So Gustav Mahler, which we already talked about, is a type of, is a person. Hamburg, so we have places in these records. We have organizations, such as the Philadelphia Orchestra, in these records, and of course we have subjects, topics in this case, such as symphonies. One of the things to bear in mind that although we have not transitioned from MARC, it is already possible to replace all of these terms in fact with identifiers, with these HTTP URI's that I was talking about. And the reason we like these HTTP URI's is because if someone encounters that URI, that identifier, and it doesn't make any sense to them, they can copy that out, they can open up their browser, they can stick it in the address bar and they can figure out what it means. So if it looks opaque to someone who's never seen that identifier before, it's relatively easy for that person to figure out what it means because we've made it completely public and we published it in such a way that, like I said, someone can just put in their browser and find out, oh, this is the identifier for Gustav Mahler. And when we start doing that, when we start taking aspects of our bibliographic records and our description, and replacing the strings with identifiers, where creating a more, a world that's based more on relationships between things. So we suddenly have a symphony and I have the composer that is Gustav Mahler and we have a symphony that has a performer and that is the Philadelphia Orchestra and a symphony that has a subject which is symphonies, and it has a manifestation in the form of a CD which is a recording of Mahler's Symphony Number 9. Which brings us to BIBFRAME and the BIBFRAME model and how that helps us to manage them of these things. There are four core classes in the BIBFRAME model: work, instance, authority, and annotation. And I'll step through each one of them and give you a definition. A work is a very, very broadly defined resource simply reflecting the conceptual essence of the catalogued item. It is so broad that one can make the argument that almost anything fits into a work. That is a feature, not a problem. It's a feature. But that type of flexibility is what we're looking for when it comes to our bibliographic data. An instance is a resource reflecting a material embodiment of the work. So to go back to that example, if the work, the abstract conceptual essence is Gustav Mahler's Symphony Number 9, the recording on CD by the Philadelphia Orchestra, conducted by Levine, is in fact an instance of that work. Authority is the concept or is the thing that represents a concept or thing. Works and instances had defined relationships to these important concepts or things. We'll spend a second or two on this. Authorities have a number of subtypes, so we had a person type and an organization type and a family, meeting, jurisdiction, place, topic, temporal concept, all of which of course will immediately evoke their corollaries in the MARC format, the 600s, the 610s, the 611s, and so on. But also the FRBR Group 2 and 3 entities. One of the ways that we've defined authority or we've created authority and we've modeled authority, at least in a BIBFRAME vocabulary, is in such a way that it could be a local access point and Paul will spend a little bit more time talking about this, I believe. And because it can be its own local access point, it can have its own HTTP URI, which means that a library could host a small page about Mark Twain and publish a URI for it so that the user could reference that URI or call upon that URI if he or she wanted to. And because it can be its own local access point, and it is its own resource, and it may have its own HTTP URI, it's its flexible design that enables data aggregation. So to put a little bit of RDF up on the screen - I don't know if it's visible all the way back; I apologize if it's not. We can see how this works. So this rather long thing at the top is an identifier for Charles Darwin. You can see that it's a type of BIBFRAME person. It has an authorized access point of Darwin, Charles, and his dates, and it has an authority reference of id.loc.gov, and that links us of course to the name authority record that you would find at id.loc.gov that has been published as linked data. But in this particular case, BIBFRAME authority, this local access point, has been augmented with additional data. Said this particular library has extracted a few variant labels in order to include his middle name, a representation in Chinese, and a representation in Arabic in case they wanted to offer alternate scripts searching for this individual inside that particular catalog. And finally, this library has added a few additional pieces of information that are traditionally carried and found in library authority records, such as a link to an image of Charles Darwin. So if they wanted to create a web page for Charles Darwin and display an image for it, here's a link right here. Added a few additional fields, such as natural history, and a link to a short biographical source. If you were to in fact follow that to its - if you were to take that URI, place it in a browser and resolve that page, you would actually find out it's a very short paragraph about Charles Darwin. The design of a BIBFRAME authority is such that the library can augment it, to augment that authority as it sees fit without having to rely solely and only on of course the information in the name authority record. Or it could choose not to. Finally, of last core class is called an annotation. And annotation is a resource that inserts additional information about another BIBFRAME resource. Annotations matter when it is important to know who makes an insertion. They are no less important than works or instances or authority; they're just different. The modeling premise is when you want to know who says something. Annotations are additional insertions about these other resources, about works and instances and authorities. They might be local, as in holdings. They might be reviews. They might be publisher descriptions. Anyone who's read a publisher description knows that a publisher description often is biased in favor of the title. It's important, therefore, to know who created that description, and that's a form of annotation. The other way to look at an annotation is in contrast to works and instances, the information in which could be controlled. So authorship - when you're talking about a work, authorship doesn't change. Huckleberry Finn will have always been written by Mark Twain. Place of publication doesn't change. So if Mark Twain was published in 1912 and 1920 and 1930 and in 1940, if there are five different manifestations of that, that publication date won't change. If they were published in five different places, those places of publication per manifestation don't change or per instance don't change. So that information could stay the same. But the information related to annotations often has a component when it's important to know who said it. So another example of that is to think of ratings. This is a mock-up of a couple of annotations. So we have a BIBFRAME work, it's called Halo: Reach, it's a game. There are two rating annotations associated with this, one of them was - one of the annotations, the annotation agent, the person asserting this additional information, was ESRB and they gave it a rating of M. The second annotation was asserted by Common Sense Media, which gave this game a rating of 16. It's fantastic to know that it was rated M and it was rated, you know, for children or young adults older than 16, 16 and older, but it's equally important to know who assigned those particular rating. So M doesn't mean anything unless we know it's the ESRB rating. And 16 doesn't mean anything unless we know it's the Common Sense Media rating. And this is what an annotation helps us do; it helps us understand who made an additional insertion. Think of - you could also think of just movie rating. In the United States, we have the MPAA, which assigns ratings such as G and PG and PG13 and R and so on and so forth. Well, Britain has its own individual system and Holland might have its own system and Japan has its own rating system. It's often not sufficient to know who - it's not just sufficient often to know what the rating was but who said it and that's, like I said, that's the modeling pattern behind an annotation, and no less important. You just need to know who said it. So taking the BIBFRAME model and its four core classes, how does it relate to RDA? And one of the things I want to say is it's relatively easy actually. The devil's in the details, of course, but it's relatively easy to take a MARC record and split it into BIBFRAME works and instances and manifestations. Sorry, BIBFRAME works and BIBFRAME instances and BIBFRAME held items, which is a form of annotation, and map those and take those and identify the information that relates to the RDA work or the RDA expression, the RDA manifestation, and the RDA item. So taking this one record, which is in fact for The Adventures of Huckleberry Finn by Mark Twain, we can quite easily and readily identify the information that pertains to the BIBFRAME work and the RDA work. In this particular case, it's a translation, so it again very easy to identify information that is still part of the BIBFRAME work but would be broken out from an RDA expression. This MARC record also of course includes information that pertains to the BIBFRAME instance or the RDA manifestations, such as the place of - the place of publication with the publisher or the year or the page numbers and a little bit of physical description of that particular BIBFRAME instead for that particular manifestation. And finally, there is actually a little bit of item information in this MARC record, too, so for BIBFRAME, that is a held item, which is a form of annotation, and the reason it's a form of annotation is it's important to know who holds the item. So it's all well and good to have a holding, but if you don't know who holds it, you only have half the infiltration and possibly, quite arguably, you're missing the most important piece of information. And of course it becomes - it becomes item level the moment that the dollar b - the O5O - comes into play. To represent that it in a slightly different way would be to show you this square on the left-hand side you have a BIBFRAME work and a BIBFRAME instance and a BIBFRAME annotation, that whole held item is a BIBFRAME annotation, and on the right the BIBFRAME work can be split out to RDA work and RDA expression as needed. The BIBFRAME instance more or less maps directly to an RDA manifestation and the BIBFRAME annotation or the held item in this case represents an RDA item. The reason for not going all four levels has a lot to do with trying to find a very workable sweet spot between the demands and the detail that we want to carry and that we feel we need in order to fully describe our resources within the libraries and our own community, but also make our information comprehensible enough and understandable to those outside of our community, such as the Googles and the Facebooks and the Bings. But going back to what I was saying about relying more on links between things, this is essentially a representation of that previous record in some ways. See you have a book that represents the original by Mark Twain of Huckleberry Finn, this work. It has an author. You'll see that both of these books have the same author, Mark Twain, except for the one on the right, which is the translation, has a translator. For some reason or another, they're identifying different subjects; that's just an anomaly in this particular slide. The English version of Mark Twain has an instance in hardcover with its own publisher and the one, the translation, has an instance that happens to be in paperwork that has its own publisher. What's actually and what this is meant to hammer home is not only are you creating relationships and relying on these relationships between these things, but we're taking the MARC record and splitting it into smaller segments and then relating them together versus creating a composite or compound record for transmission. This is a little bit of RDF. You'll see that it can be, it's fairly easy to read. Lot of lexical words embedded in there, but one of the things to make note of is the fact that you see I've broken them in to three different little section. And each one of those sections represents one of those small parts. So this top section right here is in fact BIBFRAME work with the title of Las Aventuras de Hook. It has a classification, a primary language which in this case is Spanish. It's a translation of this URI, not this resource - this resource - the resource identified by this identifier is not represented in this image, just so you know. This is the BIBFRAME instance or the manifestation. You'll see that it has dimensions and an extent and illustration note. And finally, at the very bottom, you'll see that there's a held item with the full call number. It was held by - well, it's held by our office. Not just the Library of Congress, but our office in particular, I guess. And the label at the bottom. And important to note is that it's very easy then to take those identifiers and string them together to create the composite whole that we think of today as a MARC record but when broken into smaller pieces are just linked together by these identifiers. So where does that leave us for the coming year? The person I want to say is that 2015 is a 365-day period. And I expect some of this, perhaps half of this, to happen in the second half of that 365-day period. And that of course is complicated by what's fiscal year versus calendar year. But one of the things that we have, that we are looking at, are two contracts, one of which is to develop a BIBFRAME profile editor. This is a contract that will create an application that will help people modify profiles. Now, I'm dropping this in here at the tail end. I recognize that that's a little dangerous because I've not mentioned profiles up to this point, but if I can sum this up in about three sentences, the BIBFRAME editor works on profiles. You can create your own profile and load it into the editor, which will render a handsome HTML form with which you can catalog. Right now, these profiles are only editable by technologists and developers and they have to open up, you know, text editors and look at a lot of black and white text that gets murky and they're very temperamental. If you get one thing wrong, the whole thing breaks. And so what we've done is we've issued a contract to have someone create an application that will help with the editing and the modification of those profiles to make them more user-friendly. The second contract is a small contract for a BIBFRAME search and display prototype. This is not designed to be something to replace the Library of Congress catalog -- far from it. What we want to do is we want to explore how would you - if you were to take a pile of BIBFRAME data and load it into a database of some kind, how would you query it? What type of query challenges exist? What type of display challenges exist with it? We're looking at exploring some of those aspects. There's another small contract for preservation of metadata study in BIBFRAME and finally another small contract for enhancements to SRU and Metaproxy so that if someone comes to our current SRU search point, they cannot just retrieve MARC.xml and MODS but also BIBFRAME data. And, again, the idea behind this is to get it out there, more people can see it, and become accustomed to it. As Beacher mentioned, we have plans for a pilot cataloging project. Again, deep into 2015 we expect that to begin. That is gonna require some kind of experimental online catalog. There is some very significant overlap, we hope, with that line and contract number 2, mind you. And finally we continue to evaluate the vocabulary model. We're still working on that. We're still working on knotty issues, serials being one of those knotty issues, for example. And that brings me to the end, where there is a website. Please go, take a look at it. There's lots of information. There's a high-level primer document, a number of discussion papers that talk about and look closely at some of those knotty issues. There's the vocabulary, there are a variety of tools, some of which you're about to see, the listserv, if you haven't joined it, and if anyone feels particularly adventurous, all of the code that we've developed - the transformation code, the editor - is also freely available online. So thanks so much. [ Applause ] >>Beacher Wiggins: We'll move to Paul and then do questions afterward. So with no further ado, Paul Frank. >>Paul Frank: You may have seen the advertisement for this session and it had "update in practical applications." Well, well it's sort of logical that Kevin gave the update, so the practical applications go to me. And any of you who know me, probably wouldn't associate practical with my name. And if you don't know me, I'm gonna prove it to you when I go to the editor because I'm gonna approach the editor from a cataloger's point of view. I'm a cataloger. I wasn't born a cataloger, but I'm trained as a cataloger and I have great respect for the art of cataloging. So that's my vantage point. So I said, okay, I've got to come up with another title then and so my title for this is "Coping with Anxiety" and this is actually a work in our - this is a published work in our catalog and I'm gonna use this one to do my demonstration because I sense there is a lot of anxiety out there, a lot of nervousness about something that's new. Is it worth it? How am I going to live with it? Is this the end of my career? All of these issues associated with fear and anxiety are coming out in a lot of people when I talked to them about BIBFRAME. And I'm including myself in this mix. You know, I'm pretty scared about a lot of this myself. So what I'm gonna do, just to give you an overview of what I'd like to cover, I'm gonna look at MARC because I really love MARC. I mean, I cringe when I see that "MARC Must Die" stuff, but it's going away, but I'm gonna talk about MARC. I'm gonna do a little comparison with BIBFRAME, RDF, XML. Then I want to give you a quiz on what Kevin presented, and the quiz - I'll give you a little bit more information when we get to it. It comes from a survey that we sent out to the PCC, the Program for Cooperative Cataloging membership, and others. And really all interested stakeholders in BIBFRAME and what was going on with BIBFRAME for their comment. And so we'll take this little quiz and, you know, I failed it the first time I took it, so don't worry about that. And then we'll get to the BIBFRAME editor and that's where, you know, I'm, as I said, approaching it strictly from a cataloger's point of view. And then finally I'll close with some issues that I thought you might be wondering, I mean, what might be going on in your head as we move into the future. So I'm gonna try to address some of those things. The main point that I want to make here at the beginning is that anyone who catalogs today is pretty comfortable with what is on the slide here, this template. It's a MARC template for RDA, the code RDA, to create a bibliographic record. And think about it, I mean, when you first started cataloging, for those of you who are catalogers, you had to learn what all this meant. It's not readily intelligible to a non-cataloger. I have a feeling that reference librarians are probably somewhat comfortable with this, but for the most part, this is our template. This is what catalogers have been using to create bibliographic descriptions. So we're working right in this MARC presentation. That book Coping With Anxiety, here's the MARC record for it and I'm positive that most people in this room can tell me a lot of information just based on what's on the slide about that resource. You know MARC. You really know MARC well. And in fact, in the survey that we sent out to the PCC, we asked people to self-rank themselves, their knowledge of MARC, their knowledge of RDF XML. By far, catalogers said that they would rank themselves as highly adept or expert in understanding MARC and I believe that. I don't think anyone was inflating their survey results on that. They actually, catalogers really do know MARC. So let's use one of the tools. I'm not gonna demonstrate the tool, but one of the tools that's available to everyone here is a tool on the BIBFRAME site that will take a MARC record and show you how that MARC record looks in RDF XML. And I've taken that MARC record and here we go. Now, don't think I'm duplicating the slide. There's one, two, three - three slides. Okay, I thought it was four, but it's three. So that one MARC record in RDF XML turns out to be three records, and so I was - when I looked at this, I was thinking, well, maybe this is where the fear and anxiety is starting to come out. You're looking at this and saying how am I ever gonna work with this. But you won't be. You won't be. This is a screenshot from the editor. This is what a prototype - I mean, it may change in some ways, but for the most part, you'll be working with something that's much more intelligible, even more intelligible than a MARC template would be because you see captions here that mean something. You don't have to go to the MARC authority format or the MARC bibliographic format to check, oh, what does that tag mean. It's right here. It's a display here. That's really nice. Okay, here's the true and false. Seven true or false questions. [ Background noise ] Absolutely false. Anyone want to say it's true? You gotta have a real stiff backbone to stand up and say I think it's true. I think this is, this point has been made very clear. [ Background noise ] Right. MARC Must Die, right? [ Background noise ] Okay, remember we're getting into more murky territory here. There might be a mix of answers here. [ Background noise ] Okay. I'd love to ask you why you say false, but let's save a little time and we might come back to it, maybe in the question and answer period. Yeah, this is definitely false. [ Background noise ] Yeah, you finally get a true one here. [ Background noise ] Excellent, excellent. This is where in the survey results over 800 responses to the survey, this was almost a 50-50. Yeah, the Library of Congress is not building an OPAC or an ILS to use BIBFRAME. Instead, what - ? [ Background noise ] This is the true statement, and we're making these tools available for other organizations and institutions to create those OPACs and those ILS's that will use these tools and templates. Okay, here's the one. It started easy and ended easy. True, yeah, it's definitely true. Okay, now how do you feel about that? I mean, these seven questions were sort of at the heart of the survey that we sent out that had all sorts of other information. Some of you may have completed the survey because we wanted input from as many arenas as possible. It turned out that mainly catalogers replied and that alone that is a sign to me that catalogers are very interested in what's going on in the BIBFRAME world and this environment. So the slides are going to be available to you. We have the survey results posted. I'll be sending information out about the entire survey. You can take a look and see what other types of questions were there and how the results appear. The other day - isn't it a sad commentary on technology that when you plan - even today, when you're planning on demonstrating something on the Internet in a live way, you always have to wonder, well, what happens if the Internet connection's not working? So you have to create slides like with screenshots, which is what I did in case the editor wasn't working. Then I finally realized, well, wait a minute, actually that is sort of a technological advancement because what would've happened if Thomas Edison had gone to turn on the light bulb and it didn't go on? I mean, what is he gonna say? Well, it really did go on. Or if Henry Ford was cranking the car and saying, yeah, when I crank this car, it's gonna start moving and it doesn't move. Is he gonna say, well, it really did move. At least I can say, well, there really is an editor that works if we can't actually access it live. Okay, so here we are. Here's the BIBFRAME editor - a couple of things about the editor. It's an editor alone with no back end. What do I mean by no back end? Well, right. I can put anything I want into this right now. It's not gonna save it. And why is that? Because we are not developing an OPAC or an ILS as part of BIBFRAME. Right? That's an adjunct. BIBFRAME is just a set of tools and templates and that's all we have here. So what I put in today we're not gonna be able to save and come back and look at. We can print anything out that we want and use it in the future, but for the most part, we're just - it's just an instantaneous thing. Another thing about it and thank you, Kevin, for saying that they're working on profiles. You know, there was a contract Kevin mentioned going out to develop profiles for the editor because right now we have what is called "the kitchen sink," everything is here. And when you go through it, when I show you, you're gonna say, well, wow, there's all sorts of stuff here that I don't need. So hopefully when you create your own profile, whether it's a personal profile, whether it's an RDA profile, you'll have mainly the things that you need. Just like we've - just like we create our own templates now in MARC, right. But it actually even says here "kitchen sink profile," it even includes, like, the bathtubs and the utility tubs and everything because there's some things that are just gonna really seem wild to you, especially approaching it from a cataloging point of view. But anyway, let's just take it for what it is right now. And I will say that here is, you know, this is not something that you cannot be involved in. When I'm going through this, I'm saying, hey, I don't like this. Why is this doing this? Why isn't it doing this? And I'm not the only one who can say that. Anyone who wants to play around with this can contribute to the development of this. So okay, here we go down the left-hand side of the screen. BIBFRAME Kitchen Sink Profiles, item, instance, work, a combination of the three, simple monograph. You recognize some of these terms either from your RDA training or from BIBFRAME vocabularies that Kevin's already mentioned. Let's do a new monograph. We're gonna do the complete works here. I mean, no pun intended, everything. So what do we have? Let's just go through. I clicked on that, so the template that I have here has work monograph, authorized access point, title, title variation, author - we go down the list. Everything's here. We finally get to the instance manifestation monograph, which makes sense because look at the type of information that you would be including here, an edition statement, media type, carrier, dimensions, you know, the size of the resource, the pagination, all these things that you would associate with the manifestation that you would be cataloging using RDA. And then finally when we get to the end, we come to the holdings. So these are all very familiar terms, just presented in a slightly different way here. Now, the first thing that jumped out at me from a cataloger's point of view was, why do we have authorized access point here? Well, a lot of you know often when you're identifying a resource, you will use a creator's name in this position, right? But then I thought, well, why do I have - why do I see authorized access point here but then down here I see author? Now what would the difference be? You know, here's where my cataloging [inaudible] well, we could definitely happen [inaudible] I mean, I'm wondering here, what would go - what could go in this authorized access point? A person's name? A corporate body? It could be anything. But then when I have an author editor translator, I see sort of a disconnect between these two, and I think - haven't really checked on this, but I think this is an aspect of the kitchen sink showing up to you, right? We're getting everything in there. Authorized access point is certainly an RDA vocabulary term. We talk about how authorized access points vary and access points all the time in RDA. Here's an area where we're seeing RDA perhaps in the BIBFRAME editor, some terminology that would be familiar from RDA. But let's leave this authorized access point alone for now and go to title. And I'm a terrible keyboard person when I'm working alone. It's even worse when I'm in front of people, but I'm gonna do the best I can. Just ignore the errors, but I want to enter this work Coping with Anxiety. What happens? Nothing. I'm transcribing a title here. You know, I'm not expecting anything to pop up, sort of an automatic memory of something I've done. Nothing's happening. So, okay, let's set that. So we've come up with the title for our work. Okay. Now, title variation. If you could see very closely on that MARC record, we had 10 Simple Ways to Relieve Anxiety, Fear, and Worry as the other title information. It'd be nice to get that in there, right? We click on that and a screen pops up. Now, here we go. Here is BIBFRAME vocabulary. We may be perfectly comfortable with MARC terminology, but what type of title do we have here with this other title information? Subtitle. Sure. There are all sorts of other options here. I'm not gonna key it in. I'm gonna leave it alone. I don't want to take too much time with that, but this is where I would key in the other title information. So I'm good. I'm happy with that. I'm naming a work. Remember that phrase that we all had in RDA training? You're naming the work. What about the author now? Okay, interesting things going on here. Well, the author on the title page of this resource is Edmund Bourne, B-O-U-R-N-E E-D-M-U-N-D, and there's a co-author as well, but let's just deal with the first name. Edmund Bourne, it's a person. Let's search it. [ Background noise ] Okay, now something happens. That pop-up box that says LCNAF found a match with Bourne, Edmund J. Could that be the one that I want? Possibly, right. Now because there's no back end to the editor right now, I can't go in to this record to verify, but most catalogers in this room would want to get in that record and see. Because I have what may be a variant form of that name. On the title page of my resource, it was just Edmund Bourne. There was no J there, so I want to make sure this is a one-to-one match, whether this is the right person, and if it is in fact, I may want to add to that authority record showing a different usage of the same name. But because of the lack of a back end, I'm not able to do that. Now, I love the fact that this pops up. I mean, think of what we do now with MARC cataloging, where you have to search the authority file. You go to a different file altogether. The BIBFRAME editor will configure the authority files that you want to use and pull up the information. So in this case, it's only configured to search the LCNAF. It very well could be configured to search the VIAF, Virtual International Authority File. Any file that you want could be programmed, any authoritative file would be listed it. Okay, so let's say we decided that this was not the same person, that Bourne, Edmund J. is not the same as Bourne, Edmund. Then we might want to create a new one here. [ Background noise ] Okay, now, here is where we get into the weeds, and I'm guilty of not verifying with Kevin because I thought I had it and then I thought maybe I really don't, but as someone who's worked with authority records, I need some help with this vocabulary. Now, authority assignor to me would suggest that this is the agency that's creating the authority record. Is that a safe assumption? So we would think in MARC terms at LC. I'm creating this as a Library of Congress cataloger. The authority source, perhaps the file in which the authority record will finally reside, or is this a citation that most catalogers would think of as a 670 in MARC terms to identify the source of the information that's generating the authority record? My research with the vocabulary was a little bit inconclusive. I wasn't sure that I could tell you with authority what this meant. But anyway, this would be an authority template that you would use to create a new record and here's where your input could be very useful in identification. What's authority creation all about? Identification. You know, let's make it work. So that's something I hope you all will play around with. Okay, since we're back to the kitchen sink template, we don't have an editor, we don't have a translator, we do have a date of work and it's a copyright date so I can put that. I think it was 20 - 2003, okay, sorry. I mean, it's gonna search a database to compare that date, right. That's something I'm just transcribing from the piece. Here's something very interesting and if you if you read the BIBFRAME listserv, there's been a lot of discussion about this on that BIBFRAME listserv. Place of creation. What do you think that means, place of creation? Where it written? Where it was published? If we're thinking that it's a publisher location, what do we have? Oakland, California. Any cataloger worth his or her salt would just transcribe the name of the place that appears on the resource, right? But maybe here we're looking at controlled terms for place of publication. And what happens? We're pulling up LCSH. Well, I guess it could've been published on the Bay Bridge, but anything's possible these days, right? But here's something that might appear new to you all. Using the 260 in MARC terms, the place of publication, using a controlled term for that certainly serves a useful purpose, but how many locations can one publisher have? I think on the BIBFRAME listserv someone used Oxford University Press, which would have publication loci all over the world, right? You know, so there's something where cataloger input might be helpful as we look further into BIBFRAME and using the editor here. Okay, I'm gonna not go into details for the rest of this because I think you're getting the idea, but genre - wonderful thing here. We could use this book actually has a subject, an LCSH heading, self-help techniques. Well, you know, perhaps that could be considered a genre, sort of like the "For Dummies" series. You know, the self-help things, self-help books. Maybe we could consider that a genre. All to be determined, you know, is the vocabulary there. You could use a controlled term here. LC - let's say that we did have it in the genre form, thesaurus LCGFT, we could list the term here and then for category we could put whether we're actually listing the term or maybe a code that would be used for that term. It's a wonderful example of the controlled nature of really relying a lot on controlled vocabularies in almost every part of the BIBFRAME description. Subject - well, we could do as a topic anxiety and I betcha that's gonna show up because it's definitely an LCSH heading and its wonderful keyword search. You know, it's ranked by the most prominent - and anxiety's alone, which is the one we want, but all these other LCSH headings. Nothing in LCNAF, which is good. I mean, unless we had an anxiety corporation somewhere in the world. They would've found it if it were there, so you get an idea of how the editor works with you and pulls on the authority file that you're working with to populate the information. And we go down. Intended audience. Here's something very interesting. I don't know if you're all following the developments in PSD with the demographic terms that are used for audiences that our resources are intended for or the audience of the creators and contributors of the works. There's a lot of development going on there. It's a very interesting advance in the way we describe resources. This would be a perfect location to include that type of information. Language of work, I think we're all familiar with. Going down the list, a lot of these are part of the kitchen sink that we don't really need, but we finally get to the instance manifestation. I just want to show one quick search here. Now, we've identified - we've created the work, right? Coping with Anxiety. Now we have the instance where we're gonna have the pagination, the illustrations, all that, so let's search [ Background noise ] and we're searching right against the LC database, so it's pulling up other instances. Do we find the one that we have? This is just part of searching that all of us do. I don't think the list is exhausted. There's not a lot on there, but there's a lot to go. You can check each one to see if the one that you have is there already. That's a great way towards identifying possible duplicates. It's a very easy on the eyes display. That means a lot to me as I get older. You know, easy to read. Okay, so media type, carrier type, very familiar terms from RDA, FRBR, right? They would go in the certain MARC fields that you know about now, but reported in BIBFRAME description as well. Dimensions, page number, we finally get down to the holding information for that. So that's a real quick run through on the editor. I'm gonna go quickly back to my slides because I want to leave enough time for questions at the end and the slides that I have left are really just for closing. You know, what - how does this affect me type stuff. So you may be wondering -these are the things that I think about. Do I need to know XML or RDF in order to use BIBFRAME? I don't think so. It's really great if you do. Do you have to know MARC to catalog today? Yeah. So you might need to not have such an in-depth knowledge of XML and RDF or maybe even no knowledge at all. How will my day-to-day work change in the BIBFRAME environment? Well, you're still gonna be getting resources to catalog. You might use a different interface. You're still gonna be checking authorities. You're still gonna be creating authorities. You're still gonna be checking for duplicates. I don't see much difference here. What will be different? You might need to learn some new vocabulary terms. I certainly need to learn a lot more about those terms. Will RDA still be used in BIBFRAME? Yeah, sure, I mean, a lot of people when they hear the discussion of the BIBFRAME classes, you know, the work, instance, authority, annotation, they're thinking, well, that totally does not go along with work, expression, manifestation, and item that I'm used to. But they can co-exist and RDA certainly can be used in BIBFRAME and in fact, by creating an RDA profile in the editor, when that day comes I think you'll really be amazed at what you can do. I mean, RDA will be realized in the BIBFRAME environment. What about the vocabularies? Can they coexist? Well, definitely. From a cataloging standpoint, I'm still learning the BIBFRAME vocabularies and I can see where some annotations might be needed there, but they certainly can coexist. What about NACO, the name authority file, and LCSH? How do they interact? Well, you saw an example, but I do want to mention something that's referred to as a light abstraction layer over BIBFRAME which may result in the use of multiple authority files in the future. I'm not saying we're doing that, the possibility is there to not only use the LC name authority file in LCSH but maybe other vocabularies as well, because using the identifiers, as Kevin mentioned, this type of work is much more seamless and that's why it has that phrase "light abstraction." You know, we're going into many different areas using the same protocols whereas right now we're really limited in what files we can use in our description. So this is, for me, speaking from an authorities cataloging point of view, is something that's very exciting in the future what files will - what authority files will be available in the BIBFRAME environment? My closing thoughts are that BIBFRAME serves as the foundation for the future of bibliographic description and data exchange. That's just a fact. MARC is gone. Sorry - will be gone. It integrates bibliographic data into the linked and network environment of the World Wide Web, just as Kevin very well, demonstrated very well, I think. I love the image of his example of the book that you can identify in your local library using a Google search. And certainly by making our data more available in that linked data environment, we're enhancing information discovery and promoting knowledge navigation to a much greater extent than we currently are doing with MARC. [ Silence ] >>Kevin Ford: we actually have that workflow in place. So Paul showed all of you this profile and that profile combines a work and an instance and a holding into one big gigantic web form, which is why I had to scroll forever down the page. That profile works best when you are doing original cataloging, i.e. you know that the thing is not your collection. But imagine if you're in a public library which might, you know, acquire 15 copies of the same thing, you don't want to have to, of course, repeat those steps again. I think that's what you're getting at. So imagine you're at that public library and you just received your 15th copy of the newest, I don't know, James Patterson novel. Well, you would begin by clicking on a new holding because all you really want to do at that point is add a new holding for your new thing. So you'd begin on new holding. So imagine you're in the DCPL and you click, you select District of Columbia Public Library, you've just selected your organization. Now, let's be very clear. If you were DCPL, you would have a profile that prepopulates this piece of information. I mean, I just looked it up, but every library's holding profile would of course have this information prepopulated in it. Anyway, so you save the changes and now you can see that it's held by the District of Columbia and you want to find the manifestation representing the James Patterson book that you have in your hand. I probably should have chosen Mark Twain, so let's think about Mark Twain because I know the Mark Twain is in the system. I don't know if Patterson is. You could look it up and add it and you could do a look-up right here for Huckleberry Finn to see if the manifestation you hold is in the system. And so that's what you're seeing - that's what you're seeing right here. You're seeing all the manifestations or all the BIBFRAME instances that we have for Huckleberry Finn loaded into the system. Well, actually, not all of them. You're seeing the top 10. If you have the ISBN number, you could've just used the ISBN number. I typed in the title, but you could've used the ISBN number. But let's say that you are now holding a second copy of the Magic Wagon publication of Huckleberry Finn. So instead of having to catalog it all originally, you would just select that particular one, you'd save the change, and now you're holding is for that particular instance, held by the DCPL. You could give it a shelf location or a call number and once you're done, you hit save, and it goes into the back end database. Does that address your workflow? [ Inaudible ] It's a new instance of the same work. That's fine. That's fine. So let's imagine you have a new instance of an existing work. So in that case, you could actually begin with the new instance, at which point the first thing you wanna do is associate this instance with a work. And so you click work, in this case it's still a monograph, so at this time, when I search Huckleberry Finn, you'll be able to see the dropdown options that all of those suddenly represent something that you would often see in a 240. They don't have ISBN numbers or publication information, so in this case imagine we just had a new - we just acquired a new instance of Huckleberry Finn published in 2014. So you would find the existing work, save the change, this instance is now associated with this work, and you would just go on down and you can see the carrier, volume, media type is unmediated, give the page numbers, you could give it dimensions, you could assign an ISBN number to it. And then once you're done with that instance, cataloging that instance, you hit save and you're done. But you'll see that that instance is associated with that preexisting work. So is that - right, so there are a couple of different ways to attack the issue. So you could begin with an instance and find an existing work. Or if you just acquired the 15th copy of something, you could begin with a holding and just create a new holding for an existing instance. The first one, the one that Paul showed everybody, was the kitchen sink. It assumed that neither a work nor an instance nor a holding existed in the system for that thing. [ Silence ] >>Paul Frank: I think it's too early right now. There's really nothing going on right now that I know of with respect to that. The publishing realm really invested their time into ONIX and we use ONIX data right now for the basis of stuff or basis for our own records, stuff being a non-technical term, for our own records. And the ONIX works, you know, it's controlled by them. It's in their interests. It works for them. I actually don't see them adopting BIBFRAME for our purposes. Now it would be wonderful if they started, you know, in some cases we do have providers who give us MARC records. I do foresee a future where those providers would give us BIBFRAME resources that we would load into our system just the way they give us MARC records now and load into our system. Is that addressing your question? [ Inaudible ] Right, nothing, nothing explicit is happening. It could just be a matter of our own bandwidth and not having the time. I do know that one of the more regular commentators on the BIBFRAME listserv is from Bowker. That's not ONIX, don't get me wrong, but it's someone from the publishing industry and it's specifically the ISBN industry paying attention to our efforts. We've not had any explicit discussions with the publishing industry and I think that's probably to be expected only because where we are right now is it's too early, it's not fully baked, and the publishing industry isn't gonna want to - we're not gonna be ready to have that talk yet. They're more established with their data model than we are right now. Because what's gonna happen eventually is there's gonna have to be some discussion about mapping for it. [ Silence ] >>Kevin Ford: Right, and so one of the contracts that we have out is to actually explore precisely some of these issues. So I'm not down on strings; they're absolutely essential. My complaint is from a maintenance perspective, not the user perspective. I think that, you know, users don't understand opaque URI's and I never would expect them to, and so the challenge is how to take advantage of those identifiers in our data while not sacrificing cross-referencing and browse menus. It's not about doing away with browse menus and relying entirely on one search box to rule us all in hopes that gets us there. It's about modeling our data in such a way that it's more manageable and expressive, but at the same time meets the needs of our users. So one of the big things to do with that, one of those contracts, is to explore precisely some of those issues. How is it searched? How is it displayed? How does someone go from one subject heading to another subject heading? How can someone see the cross-references and see the relationships in much the same way that researchers would expect now? [ Silence ] There is absolutely no idea, no concept, that the OPAC is gonna disappear. We still need our own system, we need a system for our own purposes and use cases and for our own users and the users who rely on those systems. It is about expanding our holdings and getting them in front of the eyes of others. [ Silence ] >>Paul Frank: Well, you're preaching to the choir here because the thing about the publisher being a controlled term really just is like chalk on, you know, fingers on the chalkboard for me because I'm that - as a cataloger, I would never think to do that. In terms of subject access, I think we still have a commitment to post coordinated strings in LCSH and there should be a way to bring those out in BIBFRAME. I mean, even - well, both. Pre-coordinated and then anticipating the post-coordinated search on that pre-coordinated term. So I don't think anything is gonna change there, but the BIBFRAME input module, if we wanna use that term instead of editor, would need to be able to accommodate that. And I don't know if Kevin has any other ideas. >>Kevin Ford: Right, so the other thing I wanted to say is that this is, in the editor right now unfortunately named and the reason I say it's unfortunately named is because it was called provider statement, but switch out the word provider with publication statement. So we have created fields in order to meet these transcription needs, I mean, the recording. I think that's what you're getting at, am I correct? These transcription needs that you have in RDA. So imagine that provider statement was rewritten as publication statement, which is what it is, it's just a mislabel in this case, or it's not a mislabel, it's just a less accurate label than it could be. So that could be the publication statement where you could capture that particular aspect of what you described. What Paul showed earlier was this place of creation that goes to place. You could look at place of creation as the, you know, you could look at the place of publication as the place of creation, but that's not - there's not a real one-to-one correlation there very often. And so place of creation, I actually don't expect, especially for monographs, place of creation to be filled out very often. I mean, it might be filled out if you're cataloging something from [inaudible], where the place of publication or place of creation made a difference. >>Paul Frank: And back to RDA, this is a very important attribute in RDA. That's why I wasn't sure if it's the place of creation of the work, of the RDA work, which is a critical attribute that we always strive to bring out if we can, or is this the place of publication which would be something that would be related to a manifestation in RDA rather than to a work. [ Silence ] Abbreviations, okay, well that's - let's not go there right now. There won't be a problem, I'll tell you that much. Okay, thank you [inaudible] and Kate. [ Silence ] >>Kevin Ford: Linked data, on the one hand, was controlled, the control data and identifiers in RDA, has a significant transcription element for logical and good reasons, and we have to capture them both. So whether or not, you know, the information is simply transcribed and that's what an institution decides to do. Whether or not the institution decides to transcribe the data and enter it as a piece of controlled information and capture it as a piece of controlled information is, again, an institutional organizational decision. I also have grand visions of in the future, you know, someone will be able to type in - to some degree, this could be built today, but not, you know, we don't have the bandwidth for that, but someone could type in a publication statement and capture that transcribed information and there were some smarts going on in the background that would be parsing the information from that field and be able to extract it and kind of automatically turn it into controlled data. So if you typed in Hamburg comma something, there would be something running and there would be a little script running in the background that would go, well, the first part before the comma is always a place, so can I match Hamburg up with something? And if the answer is yes, add that piece of information to the record but without disturbing in any way the transcribed element. Is that getting - is that helping to explain something? Anything? Okay. Okay, great, thanks. >>Beacher Wiggins: Well, needless to say, you understand why we need to have a pilot, because we want to sort out some of these issues. And as catalogers, we always get to the details. The details can be worked out, so don't go away today with too much anxiety. Go away today being primed to be ready to help us refine and move this effort forward. And so I thank profusely Paul and Kevin for their work and for breaking it down in a way that engaged the audience. [ Applause ] >> This has been a presentation of the Library of Congress. Visit us at loc.gov.