 Good morning. I'm going to call the session to order if I can. We're going to have three presentations in this session. The first will be the titles on the slide there. Making Library of this collection is discoverable on the web. Ted Vaughns from OCLC is going to present. I'll let him and the other speakers introduce themselves in more detail. By the way, my name is Tim Cole from the University of Illinois, Urbana-Champaign. And along with Gina Sarrell, I'll be doing the second presentation exposing the UIC Library catalog as linked open data. And then the third presentation by Kenny Natchlet from Montana State University, establishing semantic identity for accurate representation on the web. Cover a log round with these. We're going to ask you to hold questions until the end. And we're ready to get started here. I'm going to do my best to keep the presenters on time. Thanks. Thanks very much, Tim. This is a strange room. The fans are blowing on the chandeliers so they make this delightful little tinkling sound appropriate to the season. I feel like I'm in a school play up here with the holiday times. So I hope our presentation is as pleasant as the surroundings. So I've got the first part here. And I think, you know, as we prepared for the for the session today, we go sort of increasingly more specific and in detail. So it's a nice transition through the three presentations. I'll talk at a somewhat of a high level and in a few areas about thinking about, you know, exposing library collections on the web. How can that be more effective? You know, what are the main issues? What's the way to sort of, you know, position our brains, if you will, to, you know, to getting there, you know, with the goal of maximizing the impact of libraries? And then, of course, we'll hear more from Tim, Janina and Kenning about, you know, details. How can these things be accomplished? So first, thinking about some trends and, you know, where we are in libraries in trying to maximize the use of our collections. At OCLC, we think about a few different trends, the shift from collections to services, particularly in academic libraries. This is a clear one, you know, representing the decades shift from books on the shelf to to all of the things that a library offers and wide array of services. Search for distinctiveness. So, you know, we hear so much about born digital collections or, you know, special collections materials that are only available uniquely from an institution. So that's a real driver, particularly in the first context, where you're, you know, shifting from, you know, books on the shelf in a traditional sense to a wide variety of sources. So we think about that as search for distinctiveness. And in those, there's sort of this, you know, improvement in library workflows. How can we make things more efficient? How can we make it more effective in the systems that we use and the metadata that we use is the important part for us at OCLC. The last one is kind of our theme for the day, and that's be found on the web. So it's related to the other two, but has a special meaning in the context where we see the trends and how people come to information, how they fill out their whole research process. And there's any number of presentations on, you know, whether people use Google First or Google Scholar First or some specialist materials. And I will go into all that. We sort of take it for granted that there's value in the technical techniques, the tactics of getting library collections better positioned on the web. And so that's an important one and will be the theme throughout today. So, you know, we think from an OCLC perspective, you know, what can we do to help libraries be found on the web? So we think about a few different things here. One is a very broad ecosystem. So there's a bunch going on in this picture. I'll walk through it a bit. The top is kind of what we know today as the web environment that's enriching the discovery experience on the web. So we have, you know, DBpedia and Freebase and these various things that we know enrich the user's experience on the web. And, you know, I've got a little tiny thumbnail there of the knowledge card that is now frequent, you know, throughout the web and search engines. And so the question here is, you know, is there an environment for libraries that mirrors that? Is there an environment that we could create that would allow libraries to manage data at a high level of quality and then make it available both to the web, but also to our own discovery and other services? So that's kind of the picture on the bottom there, you know, could we create an ecosystem that's informing both of those things? And so a lot of what I'll talk about today, and I think a lot of what other folks are talking about today will address that. And then on the right hand side are the users. So I made them the biggest in the picture to remind us that they're the most important. And so, and then, you know, sort of, it's the library that is the agent in all of this, I believe. So the library will, you know, create an environment where high quality metadata can be managed, but managed in such a way that it's present in this ecosystem, that it's not siloed or managed in unknown formats. You know, you don't want to be in unknown formats on the web. So this is kind of a long term vision, and I'll come back to this at the very end. In the meantime, I'll talk about some things we're doing at OCLC and some of the things we think about. So the library knowledge graph, this is a term you may hear occasionally now, more and more talked about. I think it's a nice one. I won't go into graph theory and all of that, but, you know, these are, you know, theories coming out of mathematics and computer science, data science that say, you know, you don't just want a database of, of stuff, an inventory of stuff, you know, you want things that are relatable, you want things that show relationships between things. That's not only an important technique for being known on the web, but also sort of, you know, sound data management principles, and we need to catch up to those in a way so we can create a library knowledge graph. So features of the graph are, you know, from an end user perspective, things like knowledge cards, you know. So we ask the question, you know, can we create knowledge cards, you know, specifically in the library environment, you know, for our own discovery systems but also make them available to the web. So just an illustration of, you know, some of the components. I see some threads, you know, Dean's presentation yesterday on, you know, what they're doing at Cornell and link data for libraries group, but, you know, they're these key entities, you know, persons and works and objects, and it's nice to see that theme repeating again and again. And it says, you know, we're at the end of the era of the record as the dominant model for managing our data, and we need to move into an era where, you know, we can create these things. These entities either derivatives now or in the future sort of born entities, naturally born entities. So we can be part of that graph and part of that ecosystem that I described. So, you know, we want to make connections. We're starting to talk at OCLC about sort of, you know, relationship based discovery instead of inventory based discovery, which is kind of the, you know, the model of yesterday. So, you know, thinking again about the context of the web, we aren't inventing these things. This isn't Ted or Dean or Lorke and Dempsey are saying, you know, what if we had this graph of things? You know, this is really how things happen on the web. And it's important to keep that in mind that it's useful to understand these trends and say, well, could we position library data that way and make it available where it should be? And you can see in the commercial environment, you know, they've got their own pictures of graphs because that's how it really works, not because it makes for pretty pictures. Again, thinking about the, you know, the environment out there, I have no idea if Amazon has a fully developed graph environment behind the scenes. I don't actually know that. But we can see in the results that what they're striving for is a user experience that is easy to navigate, easy to understand. And that's a contrast from how we display data on the web in our own systems today. You know, so you could see here this sort of, you know, work and manifestation like arrangement, right? Where we have this worker expression, the English language version of this title by these authors. And then we have some, you know, selections. How would you like to receive this thing? Do you want the Kindle? Do you want the, you know, the paperback version? In library systems, we would put this on six different screens and make people sort of navigate that in a complex way. And so we need to move away from that. I think the way to move away from that is really to understand the entities that we have. So this is the experience that users expect today. And so we need to acknowledge that and figure out, you know, a data architecture that supports it. So just sort of around the wheel here, there's lots of advantages, I think, to this graph model. So we've got this graph in the middle and we've got all kinds of library workflows around. And rather than diving here, I'll talk about each one of these in a little more detail. So entities and library workflows. So if we think about discovery, we think about, you know, transformation. I said this idea of relationship-based discovery. So, you know, what if our discovery systems didn't just produce lists of records, but, you know, actual persons and places and works and, you know, the things that users are looking for, even though they don't think about it that way. So this is, you know, thinking about the future and how we can get there. And then, you know, we start to speculate about, well, what would those systems really look like? So the first picture was me just drawing something in PowerPoint. This is an actual mock-up of what these things will look like as we transform the discovery model from records to entities. So whenever I show this, people say, I like that. I think that's nicer than the catalogs we have today. We've got some sort of proof or argument for this data model and the advantages that it can bring. So thinking about cataloging, I'll say a couple of things about this. You know, my list here of why an entity-based approach is an improvement for cataloging. You know, we can link to authoritative sources as a way to improve quality. You know, introduce kind of point-and-click cataloging and managing entities, consistency with RDA. I actually think those things are all true. But I'll also say that I think we don't really know much about what cataloging will look like in this entity environment because we don't have these entities sort of out there in the wild yet in lots of systems and starting to see what works and doesn't work. And it's only when we have that that we'll really know what cataloging looks like. And I think it's probably risky to even speculate about what catalog or try it until we have the data in the field so we know really what we should be investing in our cataloging systems and tools. So library exposure, this is the theme. So I'll zip over this one. You know, we want to be found on the web. We want to connect to unique content. So that's back to that theme of, you know, searching for distinctiveness. So here's the landscape. So we've got the search engines agreeing that, you know, entity-based systems are the way to go. From a data perspective, we need to, we, meaning, you know, the big search engines agree. This is how they want to mark up their data, how they suggest data be available on websites. So they're saying if you want your data to be found on the web, we recommend this way of doing it. And if those folks across the bottom can agree on that, we should listen to that. That seems like an important thing. So we have other initiatives going on. So we have a big frame. Library of Congress folks are designing, you know, a model for representing data on the web. And you can see here on the right there's, you know, a sort of, you know, entity-based model. So that's certainly going on as a way to, you know, move us forward in explorations, experiments of, you know, how we will manage data in the future. Schema Bib Extend is kind of a way for the library community, for librarians and consultants and folks in the commercial ILS world to inform Schema. And it's working. It's quite amazing how the number of changes that Schema has made based on this librarian input. And it's very encouraging. It says that the web folks are savvy enough to listen to experts who really know about their data. And so that's been very, very, very, very positive. We think, here's how we think about data modeling at OCLC. Model things of interest to the web. So, you know, that means not necessarily just starting from what we know, start from what the web knows and what the web is telling you. And then make those things available in structures familiar to the web. So this is an argument for using Schema as a way to model things and a way to, you know, to actually make things available. Now, you know, certainly the folks at Google and all these places that are involved with Schema.org don't care about the level of granularity that we do. And so there's a gap there. So at OCLC recently, we've started to, we think, fill in some of that gap. There's something called bibliograph.net, which you can go to, which is our sort of experiment with taking Schema as a base, as a core vocabulary, and then adding some things to it. So we've added some things already around translations and we're about to add more things around persons. So that's our sort of suggestion. How can we go even beyond the Schema bib extend to round out the Schema work? Just a couple minutes left for me. So I'll go through these parts, which is, you know, here's some of the things that we've done. So we reached this conclusion, you know, we need to move from record-based model to entity-based model. So let's start putting the data out there. So we've created works and made them available. We will make them more available through our APIs as time goes on and also integrate them into our applications like Discovery. And so that people can start to see, you know, the value of that and the improvements. That we were just about to release a person entity and we combed through WorldCat and all the references and the bibliographic data to persons and we got actually a couple hundred million of them. And then we went through it again and we ended up with less than a hundred million because there are lots and lots and lots of persons that references in bibliographic data that look like the same person or look like two people, but they're really the same. So we're combing through and combing through, leaving some stuff out that we can't tell unambiguously whether it's a person or not. But it's still a really big data set. So we're using Schema. So we discovered Schema's pretty darn good for describing persons. People do it on the web. We have to add a few things to bibliograph.net and we'll do that. But this is really showing some progress, I think. And what else do we say about this? Available in, you know, various formats. So this is the nice part. So we start to make relationships between things. So link from persons to works and works from persons. And in the works we know whether there's a, the thing is buy a person and many, many different roles or about a person. You know, we can tell from the mark tagging and then we can put that into the works data. Okay, just finishing up here. Just an example of what the works looks like. Lots of links, you know, these aren't records. They're collections. They're assertions of links about a work and then about a person. So this is an early screenshot of a person. I think all I have here is just to kind of a roadmap of some things that we've done. So, you know, we started way back, you know, some time ago with Vof and Fast and in publishing link data have done a number of things. The last part is the most interesting to me and the most connected to getting our data on the web because it's, you know, it's getting this data into our applications so they can be seen. They can be harvested. They can accrue value over time. Last thing here is just coming back to our picture. You know, I think between our harvesting activity and integration into applications, you know, we really want to create this bottom environment here, you know, where libraries can collaborate at the network level, create high quality data so it can be available above and to patrons. Okay, I will be available for questions when we're done. We hope to have a few minutes left at the end so we'll see how we're doing. As Ted's ever gone, transition now from the general to some specific examples from Illinois and Montana State and Janine and I are going to talk about what we've done at UIUC specifically. And I want to take chair prerogative for just one second to comment on one thing that Ted was saying about the work with Schema.org and the Schema Extend Activity, which is taking place in a W3C community group headed by Richard Wallace. Illinois joined the World Wide Web Consortium this year and that alliance is proving to be very helpful. Some of you may have seen the presentation of Rob Sanerson and Karen Myers yesterday. Karen is actually a W3C staff about the work with the Digital Publishing Interest Group and Annotation Interest Group. They're the community groups which we've been involved in already. There's activity and data on the web for day curation. So the alliance and paying attention to what the Googles, the index and things and so on are doing for the W3C is turning out to be a very productive arrangement for us. So, as I mentioned, my name is Tim Cullum in the Mathematics and Digital Content Access Librarian. I want to give the knowledge, not only Janine and I are who are here today but also MJ Hahn and Patricia Lamperon and several others back at Illinois were involved in doing this. And basically we got a challenge from our new dean of libraries last spring, John Wilkin, who asked us to put the snapshot of our library catalog on the web, including detailed holdings information. So the goal was get our data out there and initially it was like put out as mark XML records which had been done in Michigan and it had been talked about elsewhere. But we said people aren't going to use the mark XML records for much. Let's put it out there's people who aren't as familiar with linked open data, I refer to this familiar with mark and the OCLCs of the world and so on can make use of the data. Let's see if we can transform it into linked open data to maximize its usefulness and support emerging services like those that Ted was talking about and take advantage of those services. One thing that allowed us to do was to assess and quantify the challenges of transforming our catalog records into linked open data graphs. And Jean has got to go through some of those. And also we begin to experiment not only with putting our data out there but integrating linked open data and linked open data services back into the services we provide our end users to give us a better idea of what's actually productive and important. And so that was a little bit of an overview of the project. I'm going to hand over Janina to talk about what we've learned so far along the way. Good morning. I am Janina Sarol, a visiting research programmer from UIUC. I will be describing our project workflow, the challenges we encountered, the lessons we have learned and our future plans. This is all still a work in progress and any questions or feedback will be much appreciated. So we started with almost 11 million volume level MarkXML records describing our print collections. For each bibliographically distinct entity, we combined bibliographic metadata with all associated ITEM and holding information to yield 5.5 million MarkXML records. These records were transformed into mods records so we could add URIs of available linked data sources such as WorldCat, the Virtual International Authority file, or VIAF, and the Library of Congress subject headings, or LCSH. This transformation consisted of a series of steps. The first was to transform the MarkXML records to mods records and at the same time add the WorldCat links. The next step was to replace the entity strings with VIAF links to the names. Lastly, we replaced the LCSH subject string values with the links to the subjects. We then transformed the mods records into RDF-triples that use schema.org semantics. We are serializing the RDF graphs created as RDF-XML, JSON-LD, and HTML plus RDF-A. In the future, we anticipate disseminating mods RDF and big frame RDF and creating additional services that use RDF-triples. In my remaining slides, I will be detailing interesting observations and findings to date. We decided to add WorldCat links to our records on the assumption that WorldCat records will generally have more information that is not present in ours. We generated the WorldCat link from the OCLC number. The example shown shows where the OCLC number was taken and how we represented it in mods. We were able to add WorldCat links to almost 5.3 million records, or 97% of our records. The other 3% have malformed or no OCLC numbers. Adding the VF links and LCSH links is different because in adding them, we need to do a lookup. We found an average of 1.57 names per record and added 1.04 VF links per record. This means that roughly two-thirds of the non-unique names have VF links. 3.9 million or 72% of our records contain at least one VF link. We can quantify our success in adding VF links in another way. We have 3.2 million unique name strings in our records. We found one link for 1.8 million or 57% of unique names, more than one link for 16%, and failed to find links for 27% of the names. We only added the VF link if there is exactly one match. Note, there are 1.8 million unique names with exactly one link, but we added about 1.7 million unique VF links. This is because two different name strings can point to the same person and hence the same URI. A couple of examples are shown on the screen. The first example shows one name string with the birth date and death date of the person. The other name string only has the name of the person. In the second example, the first name string is the real name of the person and the second name string is his pseudonym. For this first pass, we decided to only add links for LCSH subjects. LCSH subjects can be simple or complex. Simple subjects are a single word or phrase. In the example, the simple subject shown is a topical heading pertaining to the Vietnam War. Complex subjects are a combination of two or more simple subjects. Concatenation is indicated in the string values by a presence of dash dash. Subject headings appearing after the first dash dash are typically subdivision headings, which often have a distinct URI different from that of the authorized heading. We consider this distinction in adding the subject heading links. The complex subject in the example is songs, English, dash dash, history and criticism. The link for the second subject subdivision, which is history and criticism, is a link to a topic subdivision. But there are some cases that we could not find a topic subdivision URI and in those cases, we use the authorized heading URIs. So almost 7 out of 10 LCSH subjects in our records are complex subjects. Out of the remaining 30%, most of these subjects are topics. We were able to find 95% of the single subject topics, but only 41% for the complex subjects. Once all available link data source URIs have been added, we're ready to transform mods records to RDF triples. We decided to use schema.org because it is used by major search engines and I think it will be good for discovery. We had no problem mapping most of the mods elements to schema.org. In the elements listed, only the place of publication is not present in the native schema.org vocabulary. We used the proposed library extension to map the place of publication. But some mappings are more complicated. The name is mapped to a schema.org element depending on the role. For roles author, creator, editor and illustrator, we used the same semantics in schema.org. For all other roles, we used the contributor since no specific semantics represent these. We added the job title to specify the person or organization's contribution. We decided to map the subjects to schema about, but this is hard to describe the complex subjects. We decided to use the mods RDF namespace, which is also used by the Library of Congress in subject headings. The label on the left shows our mapping from mod subject type to mods RDF. Notice that we used schema haspart for each individual subject that is part of a complex subject. The use of haspart implies a creative work, so we are treating the mods RDF subject as a creative work. The next step is to provide additional services to our users with linked data sources. We created an HTML page that contains schema.org semantics. Instead of just adding the URIs of our linked data sources, we got their data strings and displayed them on our page. When available, we also fetched supplemental data from WorldCat. In this case, for example, the copyright year is taken from WorldCat. Sorry, the image is not very visible. The left side bar shows links to our VU fine catalog, the mark XML record, the mods record, and digitized copies of the book if present. The links at the bottom show the views of the same record in other websites. We got the data on this sample page from six different sources. Our own record, WorldCat, VIAF, LCSH, OpenLibrary, and the HathiTrust Digital Library. We had some interesting lessons and observations in our project. We learned that turning strings into URIs is a complicated task, specifically when lookups are needed. There are issues of scale, completeness, data quality, and ambiguity. When finding millions of URIs, the web services provided by the organizations do not suffice. These services often allow one lookup at a time, and when you're doing it for millions of lookups, it will take a very long time. Fortunately for us, the VIAF and LCSH data are downloadable, but it still imposes the issue of having to create our own search algorithm, which is most likely different from theirs. We also have the problem of ambiguity, especially with names. If we get multiple results, how do we know which is the correct URI? With this issue, we decided to add the URI only if there is an exact one exact match. When turning our records into graphs, we found that there are competing semantics for mapping to RDF. The library community needs to coalesce around optical semantic sets, extensions, and mappings. Currently, models and services that leverage linked open data in the library context are immature. Many organizations are still in the process of experimenting with linked data. Looking ahead for our institution, we would like to release the RDFs we created for our catalog, both for download and VL Sparkle endpoint. After we release the RDF, we will continue to explore and experiment with new services and interfaces that would help improve our library user's experience. You can go to our website at catalogdata.library.illinois.edu to get more information on this project. We also made our records available for download on this site. We're hoping to get your feedback and you can send us a note that the email address has provided. So now I will turn you over to Ken for his presentation. Thank you. So this presentation is about a specific aspect of the entity-based discussion that Ted started with a little while ago. And it's really about helping search engines like Google understand and accurately represent your library organization to users. So it's a continuation of the things, not strings discussion. I'd like to thank Patrick O'Brien, who couldn't be here today, but he helped me put this presentation together. So the point I want to make is that libraries are poorly defined and represented on the Web, specifically. Now, most of you, I'm sure, know about Google's Knowledge Graph. This is a knowledge base that's essentially invisible to us that Google introduced in 2012. And it's intended to enhance search results with semantic search information gathered from a wide variety of sources. So far, Google has rolled out three visible products from the Knowledge Graph. The first is an answer box, which really provides answers about, or facts about concepts that haven't necessarily been established as identities. The second is a carousel. And the third, which is the one that I'm focusing on today, is the Knowledge Card, which displays information about entities. And it's usually organizations or people. So I'm going to focus on the Knowledge Card, for example, of each of these. So this is what an answer box looks like in Google search results. Here I did a search for biofilm and instead of just giving me a set of websites, it also placed an answer box at the top of the results and gave me a definition of biofilm. This is an example of a carousel, that nice bar across the top. I did a search for NBA teams and it's showing me the logos of the NBA teams. And then over on the right side, you can see an example of the Knowledge Card, which gives some pretty robust information about the NBA itself as an organization. I did a survey of ARL libraries just a few days ago, 125 of them, and I searched each one in Google by the name of the library that's listed in the ARL directory. And I did a simple yes or no, did they have a Knowledge Card or not, and then I also assigned a robustness scale, which admittedly is slightly subjective, but I think you'll agree that at least the endpoints are pretty easy to figure out. If you, a robustness measure of one would be a pretty poor representation and a five would be very robust. So here's an example of what I would score as a five. The Library of Congress has a very robust Knowledge Card over on the right side. It provides a graphic of the Library of Congress, a map, a definition about the organization, the address, hours, phone number, and some other information including reviews. That's about as much information as can be displayed in a Knowledge Card. So that would have gotten a five in my scale. This on the other hand doesn't represent a one. So there's really, this indicates that there's really no information out there that Google can draw from to authoritatively establish Cornell University Library as an entity, as a thing. And this is an example of what no Knowledge Card looks like. There's simply a blank space on the right side. So here are the survey results. 43 of the 125 ARL Libraries had no Knowledge Card at all. 82 had a Knowledge Card. However, 10 of them were incorrect. They pointed to something else. 29 of them I assigned a robustness of one which left about 43 that had a Knowledge Card that had some kind of information. And a two isn't particularly good either. I mean it's just got a very little bit of information. So the point that I'm trying to make of course is that most libraries are not very well represented on the Semantic Web. And if you go back to that NBA team, NBA teams example, the NBA and many other organizations in industries are very well represented if you do those searches. Unless you think that I'm unfairly picking on ARL Libraries, let me assure you that I'm not. Because this problem hit me square between the eyes when I first got to Montana State University in 2012. I was on the job just a couple of weeks and I did a search in Google for Montana State University Library. And this is what came up in 2012. First of all, there's a very unstructured set of links, just organic links over on the left side. But the real problem, and a very poor definition that you can see by the arrow pointing to the description under the link. The real problem was over on the right side with the knowledge card. Because this was not the university where I was working. This was the knowledge card was pointing to a branch campus in Billings, Montana. Not in Boseman, Montana, where the flagship Montana State University is. So clearly Google had no idea that we existed. This is what we look at in 2014. So there's hope and we pretty much know how to fix this problem. As you can see over on the left side, there's a nice description under the initial link of the library. There's an accurate address. There's a structured set of links that reach directly into our website. There are more results from Montana.edu domain. On the right side you can see that the knowledge card is actually including our Google Plus profile. So it's pulling that in. It's giving an accurate logo an accurate location and an accurate description. Now this is still not a very robust knowledge card. I would probably give this score this about a three. But it's far better than what we had. There's still work to be done. So when I realized that we had this problem in 2012, I started to ask where does Google get its information? Well, we've all seen this as the linked open data cloud. And at the center of that cloud is dbpedia. Dbpedia is the structured data that's drawn from Wikipedia. And that tends to be the primary source for where Google gets its information. But not the only one. You notice over at dbpedia, you probably can't read this, but there's another source called Freebase. And this is another knowledge base that Google acquired some years ago and has become another primary source of information for Google's establishment, authoritative establishment of entities. Basically what I found out is that if you don't have an article in the library about the organization, then you don't exist to Google. You exist only as a string of sometimes confusing text. Other influences including Freebase are Google Places, which is sometimes now I think referred to as Google My Business and Google Plus. There are others as well. There are other signals or other sources that they take from. But these are the primary ones. Sure enough, in 2012 when I went to Wikipedia and did a search for Montana State University Library it came up and said Montana State University Library does not exist. So, here's what we look like today. We have a full good article in Wikipedia that's populating dbpedia and Google is drawing from there. So here was our dbpedia entry in 2012. You can see it recognized that something was there but it showed the message down below that said no further information is available. The requested entity is unknown. Here's what our dbpedia entry looks like in 2014. A very rich, very robust record and this is the structured data, again that Google pulls in into its knowledge graph and uses to populate the knowledge card. Our Freebase entry in 2012 was created by a bot on March 10 of 2012. It recognized that there was this thing called the Renny Library which is the other name for the Montana State University Library but it didn't know anything more than this thing this thing was maybe there so there was no other information. In 2013 five days five days after we published the Wikipedia article about Montana State University Library Freebase created another entry for us called Montana State University Library. We then went in and did a same as Renny Library is the same as Montana State University Library and if you go out and you do a search for your own libraries I encourage you to do this search all the names of the library as you know it whether it's Cornell University Library or Olin Library however you know it search all those variations and you will probably find everything from no knowledge card to knowledge cards that don't match up to inaccurate knowledge cards. So here's our Freebase entry currently Google Places in 2012 again Google realized there but it said the entry was unverified nobody had claimed the property here's our Google Plus entry in 2014 and again this is also helping to populate the knowledge card so in summary it's very important to define the library organization in Wikipedia but it's something that you have to do very carefully and if you're free at one o'clock I would encourage you to attend the early profit and Jake Orlowitz's presentation on Wikipedia in libraries because I'm sure Jake will talk about the Wikipedia culture and how you can't just throw up an article because it will in all likelihood be kicked out of Wikipedia it has to be a very well-cited, well-researched article that's not obviously self-promoting it took us probably three months I think to get our article up and engage with other trusted data sources according to Google so Freebase, Google Places Google Plus and then as Ted and Janina talked about mark up your websites with schema.org schema.org is supported and recognized by the major search engines so again the point is that libraries are poorly defined and represented on the semantic web but we know how to fix that problem mostly and I just want to give some recognition to our semantic web research team at Montana State University and OCLC and also acknowledge my appreciation for IMLS for continuing to support our search engine optimization and semantic web research thank you