HBSKnowledge: A Knowledge Graph and Semantic Search for HBS
Wise, Erin L.
Like many organizations, HBS has overlapping data in multiple repositories. These data are maintained in different ways for different business purposes, making it difficult to have a unified, cross-silo view of any given HBS-related entity. The library sought to address this challenge by creating a Proof of Concept for a Knowledge Graph that identifies unique entities (including people, companies and faculty works) across HBS repositories and defines relationships among them. This graph drives the data connections on our website, HBSKnowledge (HBSK). With this integrated structure we have uncovered many of the multiple and varying relationships among data across repositories. We have also set ourselves up to implement inferencing in future releases of the product to further enable the discovery of strategic information at HBS. In addition to structuring our data in graph form, we are using semantic search technology to enhance the search experience. We have leveraged our topic vocabularies, our company authority data, and our faculty & alumni authority data to steer users toward the most relevant information for them. The result is a product that enables discovery of 360 views of entities important to HBS. The HBSK PoC serves as an excellent product for demonstrating the promise of data integration and semantic search, the value of a Knowledge Graph in delivering on that promise, and the talent that exists in libraries for driving content structure and semantic technology. One of the lessons we (re)learned is that any AI initiative is only as good as its data inputs, and a foundation of well-structured, uniquely identified data is essential. To this end, many of our decisions about ontology and vocabulary development were informed by an understanding of library cataloging principles and practices.
 She is the manager of the information management team and Baker Library at Harvard Business School, the HBS. And her theme is HBS Knowledge, a Knowledge Graph and Semantic Search for HBS. So we are now waiting for Erin Wise to join us. She's here now. I've just heard from our direction here that she's coming. As soon as you're in Erin, go ahead and just give us a quick thumbs up and a hello that we know you're there. Hello and thumbs up, I'm here. Fantastic, wonderful. And I see and hear you excellently. Okay, great. So Erin, real quick, before we begin, could you just tell us where you're physically at right now and something that's a tourist attraction or something that should be seen when we visit that area? I am in Boston, Massachusetts. And I recommend visiting the Seaport District when you're visiting Boston. And I guess having some clam chat or soup as well. Yes, of course. Excellent. Excellent, good. So glad you could join us. As I mentioned before, Erin is the manager of the Information Management Team and Baker Library at Harvard Business School known as the HBS. Her theme today is HBS Knowledge, a Knowledge Graph and Semantic Search for HBS. Again, to our viewers, there's two ways to ask questions. We're doing great so far. You can either scroll down to your interactive tool or you'll see the QR code coming up. You can put your phone up and go ahead and use that to put in your question as well. And Erin, we have about 15 minutes for the presentations and then about five minutes for the Q&A. So if you've shared your screen and you're good to go, then I would say the digital stage is yours. Okay, thank you. So I am sharing my screen. Hopefully you all can see it. Yeah. It's great. Looks good here, yeah. Okay, excellent. Thank you. So I am pleased to present about a website that we have been developing at Harvard Business School's Baker Library. We launched it as a proof of concept last June. And the concept that we are proving is that we can use a Knowledge Graph plus Semantic Search as a way for HBS users to uncover connections across our data silos. Our experience shows that we can do a lot with a small handful of librarians and developers. And that librarians have a critical role to play in any semantic data project. So first, what is our product, HBS Knowledge or our website? So the HBS Knowledge website is our solution to a problem that many of us are struggling with, bringing together information about a resource using data across repositories. With our website, we are proposing a Knowledge Graph as a way to integrate data across repositories, a search application, a semantic search application for effective entity identification and findability of resources, and vocabularies for consistent and unambiguous language. And when I say vocabularies, I mean any controlled list of terms. I'm defining it very loosely as any controlled list of terms or entities that aids consistent indexing and accurate retrieval of resources. So who we are, we are a small team, just a few librarians and developers, and we were fortunate to be given time and autonomy to act on our ideas to develop a site that we think solves significant problems for the school. So we are a product owner, a taxonomy and ontology specialist, a semantic technology lead, a semantic search specialist and a UI designer. So some definitions, what is a Knowledge Graph? We are defining it simply as a model of a specific domain or sphere of activity. In our case, we're modeling the domain of business as practiced at HBS. The Knowledge Graph gives us a common structure for data and allows us to create relationships across repositories to provide a holistic view of entities. So in this example, and I'm afraid it probably looks quite small to you, so I apologize for that, but hopefully you can at least see that we have Amy Edmondson in the middle here in green, and she is a faculty member. And with by combining data from various sources, we can see that she is an alum of HBS and we can link to her alumni profile. We see that she's a faculty member and we can link to her faculty profile. We know that she's the author of multiple cases and publications. For example, she wrote Teaming Up to Win the Rail Deal at GE. We know that that case is about General Electric Company, and we have alums who are currently employed by General Electric Company, sorry. And so alums employed by a General Electric Company and we have alumni stories that are about those alums, those stories have topics of leadership, et cetera, et cetera. So the idea is that we just continue to make these connections and one can start at any given point in this graph and expand outwards and explore. So a definition for semantic search, we just, we define it simply as search with meaning. Semantic search uses our vocabularies and our ontology to understand the intent of queries. So in our ontology, in this example, in our ontology, Michael E. Porter is identified as a person and as a faculty member. Our faculty vocabulary lets us know that Michael Porter is an alternate name for Michael E. Porter. So a user entering a search term, Michael and Porter, or a search, yes, a combined search term, Michael and Porter. Michael Porter is recognized as a named entity as opposed to two separate keywords, Michael plus Porter. So search with meaning gives us Michael E. Porter as opposed to literal matches on query streams. We are using our library managed vocabularies such as company names and topics, along with entity to vocabularies managed at the school and at university levels, such as faculty and alumni names. In the case of faculty alumni names, sorry, in case of alumni names, we took the extra step to disambiguate alumni names by appending additional metadata for degrees and class years. So otherwise we would end up with a case where we have about 10 different people with the exact same first name plus last name combination and no way to distinguish between them when you're selecting from a list of terms. So again, I apologize for how small this slide is, but hopefully you can see the main points in blue. So we're providing an experience that probably looks familiar to you from Google. We're returning info boxes or knowledge panels on the right hand side that focus on information about a particular entity and show that entity's relationships to other resources that are important to HBS. On the left side in this view, we are showing keyword search results from our selected sources. So we have, on the right, we have explicitly related data objects from the graph. And on the left, we have keyword search results on the left. And there may or may not, there's likely some overlap between the two, but the right hand side is showing very explicitly related things that we know to be true. And the left is relying on keyword search to show you results. So why did we do this? We have multiple data sources, schemes, and vocabularies at HBS. So the situation is that we have metadata that's inconsistent across sources. We have metadata fields that even when the names of the fields are consistent across sources, they've been interpreted differently in different ways and applied in different ways from source to source. We have entities that are not uniquely identified across sources. So companies and some data sources are text strings, for example, and sources may be using different vocabularies. So local topic vocabularies, for example, would be used in different sources. One source would use one local vocabulary and another would use another local vocabulary. So we're essentially cataloging HBS assets in a consistent and systematic and controlled way. And our goal is to be able to make any data, take any data source, normalize it, scrub it, process it, and add it to our graph. So basically we're taking all the disparate sources and aggregating them into a single, intelligible, and searchable source. So to go a little deeper into our data source, we're going to go deeper into an example here. Here's an example of different metadata for the same entity. Faculty names are represented in multiple ways in the source data. So using publications in working knowledge, which is the library's online publication that features faculty work. We have a field or a property called WK faculty name. And the values in those fields are used as a byline format. So it's first name, middle initial, last name. And the relationship is not clear. So there's no stated relationship. It just says faculty name. Does that mean that this article is about the faculty? Did the faculty write it? It's not clear from the data. The faculty and research site on the other hand uses a last name, first name format, and identifies that the faculty member contributed to the work. So they have a risk contributor name field, which shows us, picks out the names are consistently identified and consistently formatted, and the relationship to the work is identified. They also have a field called HBS suggestion, which we think is related to the implementation of enterprise search at HBS, but it includes faculty names along with other data. And then again, we have alumni stories, which uses a JSON string that concatenates multiple facts about the faculty number. So we have ID, name, and title. The relationship is identified as featured. So HBS story featured faculty. Is that the same as about possibly, maybe even probably, but we're not sure. And finally, in all three sources, there is a field called HBS faculty, which uses a username format and doesn't identify a specific relationship to the publication at all. So A Brooks, A Moreno, J. McComber, no relationship identified. It's just picking out that a faculty is somehow related to this publication. And then again, another example. So of the need to resolve meaning in the data and the source data, we have different interpretations of one attribute. So HBS content type is an attribute that's common across all sources. The faculty and research data uses a vocabulary of publication types that we recognize, so books, book chapters, articles. External relations who owns the alumni stories content, they call everything all of their stories, news. So there's only one value, it's all called news. Maybe that's an article, maybe not. Working knowledge uses the content type field to describe categories of articles. So everything that they produce, we would consider an article, but they have categories that indicate specific focus, the specific focus of an article. So it might be about a podcast, it might be about a working paper that a faculty member wrote, it might be about a book, et cetera, et cetera. So how did we do it? It's a kind of very iterative process, but it's essentially the way this works is that the information management team of librarians analyzes source data. We specified how to translate the source data to our ontology, and we were simultaneously developing the ontology as we went. We translate source data and give those specifications to the technical team, just essentially our semantic technical lead and developer. He converts the source data into a triple structure with URIs for the knowledge graph. So the triple structure is subject predicate object and the knowledge graph is essentially a series of statements that look like this. So Amy Edmondson is author of Teaming Up to Win the Rail Deal. And when we apply URIs to that, we have the little piece that you see here where it's a URL and then a specified relationship and then another URL to identify the publication. So the knowledge graph is just, it's still, I think, relatively small. I think it's over a million triple statements, but this is what the data looks like. So since launching the proof of concept and demoing the site to colleagues at the business school and beyond, the use cases have been coming out of the woodwork at HBS. So some examples include using the graph to give the MBA program a view into the cases being taught in their required curriculum and giving HBS initiatives, which are topic-focused research areas at HBS, giving them a view into the publications, events, faculty and activities of the school related to the topic. They're essentially interested in promoting the activity of the school in relationship to a particular topic or industry. And these are all excellent use cases for an HBS knowledge graph and we plan to implement them. So some of our takeaways, there were many takeaways, but the ones that the highlights are that there are many principles and conventions from the library cataloging world that informed our work on the construction of a knowledge graph. So we borrowed from vocabularies for specifying relationships among entities and roles people have in relation to publications. We relied on our knowledge of library conventions for tracking name changes over time and disambiguating conflicting names. For resource description purposes, we start with the basic principle of clarifying what it is that we are trying to describe and whether and how references to the resource or entity appear in our sources. Scoping our project was key. So we focused on specific use cases and problems that we were trying to solve just a few. And the types of data that address those use cases, as well as the HBS repositories that best represented those types of data. So we chose use cases, specific content types or class types or types of data that address those use cases. And then from there, what are the specific repositories that would best help us address those use cases? And finally, if there is one thing that we learned above all, it is the importance of having unique identifiers for entities across data sources. We knew this going in, of course, but we really knew it by the time we were finished. It was so helpful to have unique identifiers anywhere we could find them in the source data. And I would say in sum that any data-driven project we undertake is highly dependent on clean, trustworthy, uniquely identified data. And when undertaking a semantic data project, you would do well to ask your friendly neighborhood librarian for help. Thank you. Thank you very much. And I'd like to give you an applause. That's our tradition here. We know we're all at home and our offices. Yes, and thank you very much for that. We have a few questions waiting. Before we begin, I wanted to ask you a quick question. I find it interesting as more and more information and data goes digital is cybersecurity an issue for you all as well, not only in that someone could come in and steal information, but also change that information that's being stored. Yeah. So it is an issue for us. And one of the reasons we, one of the other considerations for scoping our data was being very careful about what kind of data we were exposing to the outside world. So in security in that sense, we weren't thinking so much about people coming in and changing our data, but we were definitely thinking about exposing internal data to the outside world. So for now, this site is behind login. We aren't using anything that people can't already find if they have an HBS login. So as long as we're behind login, we're sort of bypassing that question. But that's one when we, the goal is to open this up more once we have more permissions and security things in place. OK, great. Thank you. OK, let me get to our audience questions. The first one we have here is, do you have feedback from users? Do they understand the knowledge graph without introduction? To me, it sounds great. Great. We have feedback from users. So the idea is not that people should have to understand the knowledge graph in order to be able to use the source. We just, when we demo the site, we try to explain what it is that we were doing and why it's different from what others may be doing at HBS right now. But really, we've had great feedback from our users. And I didn't include a slide about comments. I could have, and I guess I should have. But some of the feedback is that, while you've solved a really big problem for us, this is what everyone wants to do at HBS. They want to have this view across. And that's helped us demoing this and talking to people about it has brought out all these use cases. And people can really see themselves in it, which is fabulous for us. That's what makes it exciting. Super, that's a big plus. Good. Our next viewer, we have two questions from this person. It says here, an excellent presentation. I can only agree. I would love to understand the project development phase and the proof of concept. Can you speak more about the proof of concepts? How did you decide what data was useful? What data sources did you use for the knowledge graphs? So there were several considerations. One consideration, which was actually pretty big, was what data can we get access to pretty quickly? So some of this, we had to request permission, and it wasn't so easy to get access. But for data that's available publicly on the HBS website, so the faculty and research data, it's the citations and data about their publications and the work that they're doing, that was easy to get. The alumni stories data, which talks about alums and also faculty members. That's also on the public website, so that was easy to get. And the work knowledge data, again, was available on the public website, so that was easy to get. So we were focused primarily on publication data, people data, and organization data. OK, good. That answer was the question. Yeah, that does. A follow up to that is, is this knowledge graph available to the public? Sadly, no, not yet. Any plans? It's in the future. We have lots of plans. It's definitely something that we want to do in the future. We have a lot of permissions functionality to put into place before we can do that. But definitely the goal, so this was our proof of concept. And the goal now is to scale it up and to start expanding the knowledge graph and incorporating data sets and making it available to more people, more users, than it's currently available to. OK, great. Good. Next question here. How exactly does this ambiguation work with same name or common name researchers? The viewer says here, I did not get that. Sorry. Oh, yes. OK, so when we were working with the alumni data, we discovered all these. If we were just looking at the mean data, we saw all these duplicates, duplicate values. So we had to look at other metadata related to the alums and start and bring that in to try to disambiguate between different names. So for example, we might have had a lot of John Smiths, but those John Smiths were in different. They took maybe they were not all MBAs. Some of them were either MBA students or exec ed student alums. So we included their degrees. And then we also further disambiguated by including their class years. So if they graduated in 1995 versus 2000, so we included the degree plus class year from other metadata that was already there and just propended it to the names. Wonderful. And Erin, that's all the time we have now. So once again, I'd like to thank you for your excellent presentation and also for taking the time to answer in some of our questions. A round of applause from around the world. We have over 50 countries represented with over 300 participants. So the world will thank you to that and continued success at Harvard. Thank you. Thank you. Bye bye.
 She is the manager of the information management team  and Baker Library at Harvard Business School, the HBS.  And her theme is HBS Knowledge,  a Knowledge Graph and Semantic Search for HBS.  So we are now waiting for Erin Wise to join us.  She's here now.  I've just heard from our direction here  that she's coming.  As soon as you're in Erin,  go ahead and just give us a quick thumbs up and a hello  that we know you're there.  Hello and thumbs up, I'm here.  Fantastic, wonderful.  And I see and hear you excellently.  Okay, great.  So Erin, real quick, before we begin,  could you just tell us where you're physically at right now  and something that's a tourist attraction  or something that should be seen when we visit that area?  I am in Boston, Massachusetts.  And I recommend visiting the Seaport District  when you're visiting Boston.  And I guess having some clam chat or soup as well.  Yes, of course.  Excellent.  Excellent, good.  So glad you could join us.  As I mentioned before,  Erin is the manager of the Information Management Team  and Baker Library at Harvard Business School  known as the HBS.  Her theme today is HBS Knowledge,  a Knowledge Graph and Semantic Search for HBS.  Again, to our viewers,  there's two ways to ask questions.  We're doing great so far.  You can either scroll down to your interactive tool  or you'll see the QR code coming up.  You can put your phone up  and go ahead and use that to put in your question as well.  And Erin, we have about 15 minutes for the presentations  and then about five minutes for the Q&A.  So if you've shared your screen and you're good to go,  then I would say the digital stage is yours.  Okay, thank you.  So I am sharing my screen.  Hopefully you all can see it.  Yeah.  It's great.  Looks good here, yeah.  Okay, excellent.  Thank you.  So I am pleased to present about a website  that we have been developing  at Harvard Business School's Baker Library.  We launched it as a proof of concept last June.  And the concept that we are proving  is that we can use a Knowledge Graph plus Semantic Search  as a way for HBS users to uncover connections  across our data silos.  Our experience shows that we can do a lot  with a small handful of librarians and developers.  And that librarians have a critical role to play  in any semantic data project.  So first, what is our product, HBS Knowledge or our website?  So the HBS Knowledge website is our solution to a problem  that many of us are struggling with,  bringing together information about a resource  using data across repositories.  With our website, we are proposing a Knowledge Graph  as a way to integrate data across repositories,  a search application, a semantic search application  for effective entity identification  and findability of resources,  and vocabularies for consistent and unambiguous language.  And when I say vocabularies,  I mean any controlled list of terms.  I'm defining it very loosely  as any controlled list of terms or entities  that aids consistent indexing and accurate retrieval  of resources.  So who we are, we are a small team,  just a few librarians and developers,  and we were fortunate to be given time and autonomy  to act on our ideas to develop a site  that we think solves significant problems for the school.  So we are a product owner, a taxonomy  and ontology specialist, a semantic technology lead,  a semantic search specialist and a UI designer.  So some definitions, what is a Knowledge Graph?  We are defining it simply as a model  of a specific domain or sphere of activity.  In our case, we're modeling the domain of business  as practiced at HBS.  The Knowledge Graph gives us a common structure for data  and allows us to create relationships across repositories  to provide a holistic view of entities.  So in this example, and I'm afraid it probably  looks quite small to you, so I apologize for that,  but hopefully you can at least see  that we have Amy Edmondson in the middle here in green,  and she is a faculty member.  And with by combining data from various sources,  we can see that she is an alum of HBS  and we can link to her alumni profile.  We see that she's a faculty member  and we can link to her faculty profile.  We know that she's the author of multiple cases  and publications.  For example, she wrote Teaming Up to Win the Rail Deal at GE.  We know that that case is about General Electric Company,  and we have alums who are currently employed  by General Electric Company, sorry.  And so alums employed by a General Electric Company  and we have alumni stories that are about those alums,  those stories have topics of leadership, et cetera, et cetera.  So the idea is that we just continue to make these connections  and one can start at any given point in this graph  and expand outwards and explore.  So a definition for semantic search,  we just, we define it simply as search with meaning.  Semantic search uses our vocabularies and our ontology  to understand the intent of queries.  So in our ontology, in this example,  in our ontology, Michael E. Porter is identified  as a person and as a faculty member.  Our faculty vocabulary lets us know  that Michael Porter is an alternate name for Michael E. Porter.  So a user entering a search term, Michael and Porter,  or a search, yes, a combined search term, Michael and Porter.  Michael Porter is recognized as a named entity  as opposed to two separate keywords, Michael plus Porter.  So search with meaning gives us Michael E. Porter  as opposed to literal matches on query streams.  We are using our library managed vocabularies  such as company names and topics,  along with entity to vocabularies managed at the school  and at university levels, such as faculty and alumni names.  In the case of faculty alumni names, sorry,  in case of alumni names, we took the extra step  to disambiguate alumni names by appending additional metadata  for degrees and class years.  So otherwise we would end up with a case  where we have about 10 different people  with the exact same first name plus last name combination  and no way to distinguish between them  when you're selecting from a list of terms.  So again, I apologize for how small this slide is,  but hopefully you can see the main points in blue.  So we're providing an experience  that probably looks familiar to you from Google.  We're returning info boxes or knowledge panels  on the right hand side that focus on information  about a particular entity and show that entity's relationships  to other resources that are important to HBS.  On the left side in this view,  we are showing keyword search results  from our selected sources.  So we have, on the right,  we have explicitly related data objects from the graph.  And on the left, we have keyword search results on the left.  And there may or may not, there's likely some overlap  between the two, but the right hand side  is showing very explicitly related things  that we know to be true.  And the left is relying on keyword search  to show you results.  So why did we do this?  We have multiple data sources, schemes,  and vocabularies at HBS.  So the situation is that we have metadata  that's inconsistent across sources.  We have metadata fields that even when the names of the fields  are consistent across sources,  they've been interpreted differently in different ways  and applied in different ways from source to source.  We have entities that are not uniquely identified across sources.  So companies and some data sources are text strings,  for example, and sources may be using different vocabularies.  So local topic vocabularies,  for example, would be used in different sources.  One source would use one local vocabulary  and another would use another local vocabulary.  So we're essentially cataloging HBS  assets in a consistent and systematic and controlled way.  And our goal is to be able to make any data,  take any data source, normalize it, scrub it,  process it, and add it to our graph.  So basically we're taking all the disparate sources  and aggregating them into a single,  intelligible, and searchable source.  So to go a little deeper into our data source,  we're going to go deeper into an example here.  Here's an example of different metadata for the same entity.  Faculty names are represented in multiple ways  in the source data.  So using publications in working knowledge,  which is the library's online publication  that features faculty work.  We have a field or a property called WK faculty name.  And the values in those fields are used as a byline format.  So it's first name, middle initial, last name.  And the relationship is not clear.  So there's no stated relationship.  It just says faculty name.  Does that mean that this article is about the faculty?  Did the faculty write it?  It's not clear from the data.  The faculty and research site on the other hand  uses a last name, first name format,  and identifies that the faculty member  contributed to the work.  So they have a risk contributor name field,  which shows us, picks out the names are consistently identified  and consistently formatted,  and the relationship to the work is identified.  They also have a field called HBS suggestion,  which we think is related to the implementation  of enterprise search at HBS,  but it includes faculty names along with other data.  And then again, we have alumni stories,  which uses a JSON string that concatenates multiple facts  about the faculty number.  So we have ID, name, and title.  The relationship is identified as featured.  So HBS story featured faculty.  Is that the same as about possibly,  maybe even probably, but we're not sure.  And finally, in all three sources,  there is a field called HBS faculty,  which uses a username format  and doesn't identify a specific relationship  to the publication at all.  So A Brooks, A Moreno, J. McComber,  no relationship identified.  It's just picking out that a faculty  is somehow related to this publication.  And then again, another example.  So of the need to resolve meaning in the data  and the source data,  we have different interpretations of one attribute.  So HBS content type is an attribute  that's common across all sources.  The faculty and research data uses a vocabulary  of publication types that we recognize,  so books, book chapters, articles.  External relations who owns the alumni stories content,  they call everything all of their stories, news.  So there's only one value, it's all called news.  Maybe that's an article, maybe not.  Working knowledge uses the content type field  to describe categories of articles.  So everything that they produce,  we would consider an article,  but they have categories that indicate specific focus,  the specific focus of an article.  So it might be about a podcast,  it might be about a working paper  that a faculty member wrote,  it might be about a book, et cetera, et cetera.  So how did we do it?  It's a kind of very iterative process,  but it's essentially the way this works  is that the information management team of librarians  analyzes source data.  We specified how to translate the source data  to our ontology,  and we were simultaneously developing the ontology  as we went.  We translate source data  and give those specifications to the technical team,  just essentially our semantic technical lead and developer.  He converts the source data into a triple structure  with URIs for the knowledge graph.  So the triple structure is subject predicate object  and the knowledge graph is essentially  a series of statements that look like this.  So Amy Edmondson is author of Teaming Up to Win the Rail Deal.  And when we apply URIs to that,  we have the little piece that you see here  where it's a URL and then a specified relationship  and then another URL to identify the publication.  So the knowledge graph is just,  it's still, I think, relatively small.  I think it's over a million triple statements,  but this is what the data looks like.  So since launching the proof of concept  and demoing the site to colleagues  at the business school and beyond,  the use cases have been coming out of the woodwork at HBS.  So some examples include using the graph  to give the MBA program a view into the cases  being taught in their required curriculum  and giving HBS initiatives,  which are topic-focused research areas at HBS,  giving them a view into the publications, events,  faculty and activities of the school related to the topic.  They're essentially interested in promoting the activity  of the school in relationship  to a particular topic or industry.  And these are all excellent use cases  for an HBS knowledge graph and we plan to implement them.  So some of our takeaways, there were many takeaways,  but the ones that the highlights are that there are many  principles and conventions from the library cataloging world  that informed our work on the construction  of a knowledge graph.  So we borrowed from vocabularies  for specifying relationships among entities and roles  people have in relation to publications.  We relied on our knowledge of library conventions  for tracking name changes over time  and disambiguating conflicting names.  For resource description purposes,  we start with the basic principle of clarifying  what it is that we are trying to describe  and whether and how references to the resource  or entity appear in our sources.  Scoping our project was key.  So we focused on specific use cases and problems  that we were trying to solve just a few.  And the types of data that address those use cases,  as well as the HBS repositories  that best represented those types of data.  So we chose use cases, specific content types  or class types or types of data  that address those use cases.  And then from there, what are the specific repositories  that would best help us address those use cases?  And finally, if there is one thing that we learned above all,  it is the importance of having unique identifiers  for entities across data sources.  We knew this going in, of course,  but we really knew it by the time we were finished.  It was so helpful to have unique identifiers  anywhere we could find them in the source data.  And I would say in sum that any data-driven project  we undertake is highly dependent on clean,  trustworthy, uniquely identified data.  And when undertaking a semantic data project,  you would do well to ask your friendly neighborhood librarian  for help.  Thank you.  Thank you very much.  And I'd like to give you an applause.  That's our tradition here.  We know we're all at home and our offices.  Yes, and thank you very much for that.  We have a few questions waiting.  Before we begin, I wanted to ask you a quick question.  I find it interesting as more and more information and data  goes digital is cybersecurity an issue for you all as well,  not only in that someone could come in and steal information,  but also change that information that's being stored.  Yeah.  So it is an issue for us.  And one of the reasons we, one of the other considerations  for scoping our data was being very careful about what kind  of data we were exposing to the outside world.  So in security in that sense, we weren't thinking so much  about people coming in and changing our data,  but we were definitely thinking about exposing  internal data to the outside world.  So for now, this site is behind login.  We aren't using anything that people can't already find  if they have an HBS login.  So as long as we're behind login, we're  sort of bypassing that question.  But that's one when we, the goal is to open this up more  once we have more permissions and security things in place.  OK, great.  Thank you.  OK, let me get to our audience questions.  The first one we have here is, do you have feedback from users?  Do they understand the knowledge graph without introduction?  To me, it sounds great.  Great.  We have feedback from users.  So the idea is not that people should  have to understand the knowledge graph in order  to be able to use the source.  We just, when we demo the site, we  try to explain what it is that we were doing  and why it's different from what others may be doing at HBS  right now.  But really, we've had great feedback from our users.  And I didn't include a slide about comments.  I could have, and I guess I should have.  But some of the feedback is that, while you've  solved a really big problem for us,  this is what everyone wants to do at HBS.  They want to have this view across.  And that's helped us demoing this and talking to people  about it has brought out all these use cases.  And people can really see themselves in it,  which is fabulous for us.  That's what makes it exciting.  Super, that's a big plus.  Good.  Our next viewer, we have two questions from this person.  It says here, an excellent presentation.  I can only agree.  I would love to understand the project development phase  and the proof of concept.  Can you speak more about the proof of concepts?  How did you decide what data was useful?  What data sources did you use for the knowledge graphs?  So there were several considerations.  One consideration, which was actually pretty big,  was what data can we get access to pretty quickly?  So some of this, we had to request permission,  and it wasn't so easy to get access.  But for data that's available publicly on the HBS website,  so the faculty and research data, it's the citations and data  about their publications and the work that they're doing,  that was easy to get.  The alumni stories data, which talks about alums  and also faculty members.  That's also on the public website, so that was easy to get.  And the work knowledge data, again,  was available on the public website,  so that was easy to get.  So we were focused primarily on publication data, people data,  and organization data.  OK, good.  That answer was the question.  Yeah, that does.  A follow up to that is, is this knowledge  graph available to the public?  Sadly, no, not yet.  Any plans?  It's in the future.  We have lots of plans.  It's definitely something that we want to do in the future.  We have a lot of permissions functionality  to put into place before we can do that.  But definitely the goal, so this was our proof of concept.  And the goal now is to scale it up  and to start expanding the knowledge graph  and incorporating data sets and making it available  to more people, more users, than it's currently available to.  OK, great.  Good.  Next question here.  How exactly does this ambiguation work  with same name or common name researchers?  The viewer says here, I did not get that.  Sorry.  Oh, yes.  OK, so when we were working with the alumni data,  we discovered all these.  If we were just looking at the mean data,  we saw all these duplicates, duplicate values.  So we had to look at other metadata related to the alums  and start and bring that in to try to disambiguate  between different names.  So for example, we might have had a lot of John Smiths,  but those John Smiths were in different.  They took maybe they were not all MBAs.  Some of them were either MBA students or exec ed student  alums.  So we included their degrees.  And then we also further disambiguated  by including their class years.  So if they graduated in 1995 versus 2000,  so we included the degree plus class year  from other metadata that was already there  and just propended it to the names.  Wonderful.  And Erin, that's all the time we have now.  So once again, I'd like to thank you  for your excellent presentation and also  for taking the time to answer in some of our questions.  A round of applause from around the world.  We have over 50 countries represented with over 300  participants.  So the world will thank you to that  and continued success at Harvard.  Thank you.  Thank you.  Bye bye.
13_Erin_L_0_443.png 13_Erin_L_444_551.png 13_Erin_L_552_623.png 13_Erin_L_624_2903.png 13_Erin_L_2904_3863.png 13_Erin_L_3864_5147.png 13_Erin_L_5148_5867.png 13_Erin_L_5868_7715.png 13_Erin_L_7716_7775.png 13_Erin_L_7776_8459.png 13_Erin_L_8460_9899.png 13_Erin_L_9900_11039.png 13_Erin_L_11040_12611.png 13_Erin_L_12612_14531.png 13_Erin_L_14532_18047.png 13_Erin_L_18048_19715.png 13_Erin_L_19716_21935.png 13_Erin_L_21936_23255.png 13_Erin_L_23256_26363.png 13_Erin_L_26364_26507.png 13_Erin_L_26508_28799.png 13_Erin_L_28800_29039.png 13_Erin_L_29040_29303.png 13_Erin_L_29304_30779.png 13_Erin_L_30780_31235.png 13_Erin_L_31236_32831.png 13_Erin_L_32832_32927.png 13_Erin_L_32928_33047.png 13_Erin_L_33048_34019.png 13_Erin_L_34020_34415.png 13_Erin_L_34416_36275.png 13_Erin_L_36276_36365.png