Person Entities: Lessons learned by a data provider
Chapman, John W.
Continuing the longstanding research program by OCLC in the field of linked data, recent projects have focused on creating sets of entities of high interest for any organization wanting to utilize linked data paradigms. Through intensive mining and clustering of WorldCat bibliographic data, name and subject authority files, and other related data sets, OCLC has produced over 300 million entity representations. These clusters pull together and represent creative works, and persons related to those works. OCLC has engaged with a number of libraries and organizations to create and experiment with this data. A pilot project during October 2015-February 2016 to explore new methods of providing access to Person entities provided a number of new directions and insights. The core purpose of the work is to understand how these entities might best be leveraged to make library workflows more efficient, and to improve the quality of metadata produced in the library sector. This presentation will provide a background on data used in the project, as well as the development of services and APIs to provision the data. It will address challenges and opportunities in the area of creating and managing entities, and ways in which they could be improved and enriched over time.
 You walked around and traded business cards. You have new ideas to talk with people about. So the first talk after the break, we're now in the linking things session of the day. And I'm excited to introduce John Chapman. He is a senior product manager for metadata services at OCLC. He's helped lead product strategy and planning of OCLC's many exciting linked data projects on other product development. He'll be talking about person insties, lessons learned by a data provider. Hi everyone. My role at OCLC is that of, as was mentioned, a senior product manager in metadata services. As such, I'm responsible for cataloging applications. But I also care about the data, obviously, that those cataloging applications use. We saw an opportunity to try to learn more about the entities that we had created in house and see how we might be able to provide better access to those entities to leverage those within cataloging workflows. Over the past several years, we've released WorldCat works and WorldCat persons, which between them total more than 300 million separate entities. What we found, though, we sort of had this moment about we've created all these entities, but people aren't really using them as much as we would like. So we asked the question about how could we make it easier for people to use them instead of just having to find them through following links? So how could we index them? How could we provide services around them to improve that situation? So today I'll just be talking about essentially how we enhanced, provided the data, some of the lessons that we learned around that, and then how we see the discussion moving forward. So as I mentioned, the primary goal was to improve access to our entities via an API-first type model. What I mean by that is just that we didn't stress at the beginning providing any sort of UI for this. Especially as we started developing the strategy, we decided that most of the institutions that would be using it would be wanting to write their own tools, perhaps write their own UIs to consume that, so we didn't prioritize the creation of the UI. The two major workflow considerations that we wanted to work in, treat as use cases, were when you're creating metadata, how could you most easily find and refer to WorldCat person entities? And then we also wanted to work around some use cases about improving navigation affordances in terms of possibly knowledge cards, provide tools of that sort so that people could put those into a UI. We had a small group. The group included members of some institutions here in the audience. We had National Library of Poland, National Library of Germany, Cornell, Harvard, Library of Congress, National Library of Medicine in the U.S., Stanford, UC Davis, Pepperdine, and Drexel, as well as the Swiss Bib Organization that we heard from earlier today. The pilot that we ran against these person entities had a very short time frame. We did it basically in October to February. Then we had a sharp cutoff. We actually shut the service down after that time frame. I had two phases, the first one being sort of the same as identifier lookup, very simple. A second phase was much more involved and involved string matching for person names. We realized going into phase one that everybody really, really wanted the stuff in phase two, but we had to work towards that. We couldn't offer it all immediately. As I mentioned, phase one being a same-ass service. What we did here was we started with VF and what VF does of matching between the different authority files. We didn't take VF data, but we used the same algorithms and rebuilt it. We provided additional links based on anything we could find through analyzing, as I said, not only the VF corpus, but WorldCat. Some of the projects that some people might be familiar with, the WorldCat entities, using some of the strategies that we learned there. This is basically an ID to ID matching. The request that went into the service would have to include a known identifier. Then for matchback, you would get our person entity URI, which you can find down here in the list somewhere, as well as all the other matching URIs. Something to note here, in the pilot, we allowed discussion about the difference between authority data and person data, the difference between modeling, collection of names versus modeling information about a person. Note here in the list that we have several examples of URIs that refer to this person as a topic, so not just a name reference. Phase two, as I mentioned, much more involved. This included a text-based search. The data stored in the entity included a lot more. We started storing a preferred name or preferred names in a bunch of different name forms, including language tags. Also important here to note is that we provided things that we called roles, topics, and also provided a score. Roles and topics were determined going against bibliographic data, so essentially the most prevalent subject headings among the bibliographic entities that the person was associated with. That became the topic. And then the most prevalent role that that person has been assigned in terms of those same resources in WorldCat became the role. During the pilot, we learned that in some cases more was better because the top topic might not make a lot of sense or the top role might not make a lot of sense just on a purely statistical basis. This is especially a problem with some folks who aren't traditional authors of works. The score then is more complicated. This was provided in the response to a search. So if you got a result list back, entered a name into the service, got 10 results back, one option was to rank those by a score. And I'll show an example of that in a minute. So what that is is basically imagine sort of a page rank type of thing. So how interconnected is that person within WorldCat? So we found that to be especially useful for some of the partial matches that we offered via the service on the fuzzy matching. So I was told that people wouldn't mind if I put up some JSON. So I'm going to do that. So this is a single result from a search. So this search is simplified, but I could add parameters in terms of a result set of one, 10. So one of the results here, we get the entity ID. We get a default label, birth date, role, topic, the scores I mentioned. Scores, I saw scores from something like 40,000 down to two. So there's a fairly wide range. A particular note here are all the language labels that we have. This was very intense processing to do this. And it wasn't very neat, if I can explain that for just a minute. So essentially what we wanted to do was allow for searches to be focused towards a specific language. Unfortunately, the connection between specific authority files and specific languages isn't always neat. So we had to make some educated guesses, in some cases, to distinguish between, say, British English and American English. Some authority files aren't dedicated to a specific language, and that makes things a little bit more difficult. But you can see here, I actually snipped the number of language labels here in brackets there, got a little long. But those would be things that you could search against. Also during the pilot, we heard some requests for improving searching against some of these different parameters. So could I combine a name search with a language or something like that? We didn't get there in our short timeframe. We also had some interesting discussions around whether that would require re-indexing and creating new indexes or whether we wanted to do that through more of a bundle of terms type model. Although we tried to make it an API-first model, we did also provide some demo web apps. So the first type of demo web app we did basically used this type of response form to build sort of a bento box type display of ranked results, prettifying and formatting some of the information that you see here on the screen, and then obviously ranking those by the score. And then upon clicking on one of those, you would get a nice display of that entity. So just a really a mock-up here. Well, not a mock-up, but this is a prototype that we developed and delivered during the pilot. What's interesting here is that you can see some of the information, the picture, the little tagline Spanish painter and printmaker, and that extensive description are actually not stored in the person entity. They're just stored as links. And then at render time, we're going out and grabbing that and then displaying it. But you can see the alternate names are listed, same as relationships are listed. And then something fun that we experimented with was grabbing the family relationships out of WikiData. I don't have a good example, but for some of those, we could actually link back to other person entities. So some lessons learned. I have lessons learned sort of from the data aggregator view, from the service provider view, and then from pilot activity participants type of view. So the first just being that many sources are available. No single source is good at everything. Not naming names, but we found that some files would be really good at dates, and so we trusted those. But that file might be excellent in a specific language format, so we would trust that one a little bit more. So the quality does vary widely by element type. So when we're talking about weighting, we're talking about preferring, we're talking about adjusting, that's not at the source level, that's at that field per source level. We also feel that data aggregation is crucial. So a lot of the crunching that we did to try to improve search results really benefited from the fact that we had all of this data in-house, we talked about is providing context at scale. So you can bring a lot of things to bear in terms of how important a person is within the corpus, and then all the different ways that information about that person can be provided. When weighting and scoring are absolutely crucial, goes along with that scale. So from the service consumers view, the first thing I wanted to mention was just that remembering our workflows, remembering if I'm trying to enter information, a link for a person entity, I need to have that context. I need to have, if I'm searching for a John Smith, I got to find that right John Smith. So having those roles, having those topics, having the dates available right there in that first search result response is critical and useful. Obviously context being key to names, as the victim of kind of a common name myself, I feel this one deeply. So there's a lot of John Chapman's in the database. And then I mentioned a little bit earlier about the difference between possibly indexing more terms versus having more terms piled in and available for search. Indexing is expensive, and so that's something that we talked about a lot. The language support, very important, but it is inexact, so we saw some edge cases that maybe were not edge casey enough popping up. The nice thing about language tagging would be things like, for example, if you know a name is Chinese, you can go ahead and treat the honorifics in a specific way that you need to do differently than if it's an English name. So getting that right is great. It's difficult to get that right in an automated fashion 100% of the time. We also have an unsolved problem around sparse clusters. So the person entity data follows a classic long tail model. So we created something like 120 million person entities. There's roughly 17 million of those that are really highly cross-linked that we can bring a lot of this processing to bear. A lot of the other stuff is one OCLC number, one name. We don't know a lot else. So something that people asked about during the pilot, and we, again, we didn't have time to explore it more fully, but we can think of a lot of good ways to get there would be how to get those clusters better integrated within the whole network. The combined view then, if you can't find that entity, how can you create a new ID and how will that work into an effective workflow? So when you're minting IDs, any little bit of friction means that you slow that workflow down very quickly. We heard requests about, you know, can we enhance the service to create a new person entity? So where do we go from here? From an OCLC point of view, we want to continue starting and then ending these pilots and experiments. So have processed them quickly. We want to move more from projects to production. We relied heavily on VF, on ISNI, on WorldCat identities. We're very interested in continuing to move those to some more sustainable and persistent systems at an operational level. We want to consider positive and negative incentives. So what are the incentives to use particular identifiers and to participate in their enhancement, especially in an environment where things are being clustered and matched? Where is the biggest bang for the buck? Where is the biggest return on investment in terms of correcting and enhancing metadata within a vastly networked graph? And then also, we need to surface that local expertise to build context. So there are many pockets of specialized knowledge around the world. Bringing those in brings yet another perspective, yet another angle to view things on. So then in that bigger point of view, single aggregation is never going to be complete and comprehensive. We want to encourage some more focused experimentation in this way. We're really happy with how we were able to iterate and improve the services that we provided. And we'd like to continue to work together, whether it's VF, ISNI or WorldCat to better represent these connections between bibliographic data and traditional authority data. Lastly, I can take questions. I also want to thank my colleagues who worked with me and helped out with the service, provided the technical backbones, so Jeff Mixter, Steven Shindehedy and Bruce Washburn. Thank you. Thank you, John. That was excellent. So do we have questions for the speaker? Yes. Thank you. Thank you very much for this talk, John. To catch up your last sentence, let's continue to work together. Because this was, as you mentioned, this was part of the second phase of this project, and I gave you some feedback. And I think it was quite positive feedback because, yes, I made some tests and it would be very helpful for us to link our person entities against other repositories. But I haven't heard anything since last February what's going on and how we could use your person entity API. So to be clear, we have a couple different versions, unfortunately, of person data. So as I mentioned for the past two and a half, three years, we've been publishing WorldCat entities. For this pilot, what we did was essentially create an enhanced version of these person entities and then provide access to them via the service. In terms of moving the service into production along the way, we realized that many of the systems that we rely on needed to be brought to a better production environment. A lot of what I described is manual effort, semi-automated, and wasn't part of our main production workflow. So we are waiting to announce availability until we have this better supported and it can commit to it as a sustainable project. We know in the past, CLC has had services that have sort of an unclear status in terms of whether they're experimental or production. We don't want to do that again. And that's one of the reasons why we had that firm stop date. So. Are there other questions? Thank you. On the user interface, I see the family relationship box. And how do you build this box? Are textual information or relations? Real relation? I'm afraid I don't understand the question. On your slide, I see a box with family relation. Oh, yes. Okay. On your slide. And I would like to know if you create object properties with real relation between persons or are only textual information to create this network? So for that feature, what we were able to do is pull in data from WikiData for the display here. What we were also able to do as an experiment but not sort of fully within the databases, if these names that were referred to, for example, if his father was represented by a person entity, then we could also link, provide that as a link instead of just text. That was a messy and not very successful experiment, so we didn't really roll that out. Other questions? Hi, John. One of the things I've been interested in with things like VF, and I think it applies to these computed personal identities as well, is how does one think about persistence in this space? So I can imagine seeing them as a lookup and then you find some other more managed identifier like the ISNI which you record, but if there's a potential for the VF or the person entity to change on a recomputation, how do you think about managing that in a persistent sense? So we know that the drift in VF identifiers is a huge problem. We wrestled with that in the project. Our goal would be to provide person entity IDs that were persistent and sustainable and linked to whatever they could when you resolved them. As I mentioned, we don't want to roll something out that we're not fully behind in terms of the IDs being persistent, so much of the work you've seen here is not production ready yet. So I think that in order for the, I think this use case where at the ID level when you resolve that ID, you get not just links but context is very powerful, so we want to do it right and roll that out when it's ready. This is a difficult question having to do with the read, write, web and closing the loop of data. Where do we report problems and do we have a sort of workflow for handling problems? I'm right now looking at the page for Stephen Hawking and when it says his name is also Jane Hawking scientist, I mean the primary name and a few other names that are maybe his relatives but obviously not his own. So is there some sort of workflow of reporting these errors back to the providers somehow? So the errors that you mentioned if I understand them may be in the data providers or it may be in our computation. And so in terms of reporting errors, this is primarily, you know, we have email addresses that, you know, support requests or record corrections can go to. As a semi-production service, we would just route those to the right person. Any other questions? This may be something you can't really talk about in detail but given that you have really large numbers of data sets to crunch, could you hint at the infrastructure you're using for that? Sure. So the, again, I'm a product guy. So at the database level, we're using Hadoop and HBase to build the entities. And then in terms of the pilot and how the search was done against those entities, that's an elastic search implementation. And then our UI stack is Node.js and some Angular.js for some particular implementations. In terms of the data processing though, it's multiple iterations through, first the authority files and then through the bibliographic data, gathering IDs and then further steps of mapping those building interlinks between them. Again, possibly at the wrong conference because I can't explain it in more detail. All right. Thank you very much for that. Yay. Yeah. We can clap again. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.
 You walked around and traded business cards.  You have new ideas to talk with people about.  So the first talk after the break, we're now in the linking things session of the day.  And I'm excited to introduce John Chapman.  He is a senior product manager for metadata services at OCLC.  He's helped lead product strategy and planning of OCLC's many exciting linked data projects  on other product development.  He'll be talking about person insties, lessons learned by a data provider.  Hi everyone.  My role at OCLC is that of, as was mentioned, a senior product manager in metadata services.  As such, I'm responsible for cataloging applications.  But I also care about the data, obviously, that those cataloging applications use.  We saw an opportunity to try to learn more about the entities that we had created in  house and see how we might be able to provide better access to those entities to leverage  those within cataloging workflows.  Over the past several years, we've released WorldCat works and WorldCat persons, which  between them total more than 300 million separate entities.  What we found, though, we sort of had this moment about we've created all these entities,  but people aren't really using them as much as we would like.  So we asked the question about how could we make it easier for people to use them instead  of just having to find them through following links?  So how could we index them?  How could we provide services around them to improve that situation?  So today I'll just be talking about essentially how we enhanced, provided the data, some of  the lessons that we learned around that, and then how we see the discussion moving forward.  So as I mentioned, the primary goal was to improve access to our entities via an API-first  type model.  What I mean by that is just that we didn't stress at the beginning providing any sort  of UI for this.  Especially as we started developing the strategy, we decided that most of the institutions that  would be using it would be wanting to write their own tools, perhaps write their own UIs  to consume that, so we didn't prioritize the creation of the UI.  The two major workflow considerations that we wanted to work in, treat as use cases, were  when you're creating metadata, how could you most easily find and refer to WorldCat  person entities?  And then we also wanted to work around some use cases about improving navigation affordances  in terms of possibly knowledge cards, provide tools of that sort so that people could put  those into a UI.  We had a small group.  The group included members of some institutions here in the audience.  We had National Library of Poland, National Library of Germany, Cornell, Harvard, Library  of Congress, National Library of Medicine in the U.S., Stanford, UC Davis, Pepperdine,  and Drexel, as well as the Swiss Bib Organization that we heard from earlier today.  The pilot that we ran against these person entities had a very short time frame.  We did it basically in October to February.  Then we had a sharp cutoff.  We actually shut the service down after that time frame.  I had two phases, the first one being sort of the same as identifier lookup, very simple.  A second phase was much more involved and involved string matching for person names.  We realized going into phase one that everybody really, really wanted the stuff in phase two,  but we had to work towards that.  We couldn't offer it all immediately.  As I mentioned, phase one being a same-ass service.  What we did here was we started with VF and what VF does of matching between the different  authority files.  We didn't take VF data, but we used the same algorithms and rebuilt it.  We provided additional links based on anything we could find through analyzing, as I said,  not only the VF corpus, but WorldCat.  Some of the projects that some people might be familiar with, the WorldCat entities, using  some of the strategies that we learned there.  This is basically an ID to ID matching.  The request that went into the service would have to include a known identifier.  Then for matchback, you would get our person entity URI, which you can find down here in  the list somewhere, as well as all the other matching URIs.  Something to note here, in the pilot, we allowed discussion about the difference between authority  data and person data, the difference between modeling, collection of names versus modeling  information about a person.  Note here in the list that we have several examples of URIs that refer to this person  as a topic, so not just a name reference.  Phase two, as I mentioned, much more involved.  This included a text-based search.  The data stored in the entity included a lot more.  We started storing a preferred name or preferred names in a bunch of different name forms,  including language tags.  Also important here to note is that we provided things that we called roles, topics, and also  provided a score.  Roles and topics were determined going against bibliographic data, so essentially the most  prevalent subject headings among the bibliographic entities that the person was associated with.  That became the topic.  And then the most prevalent role that that person has been assigned in terms of those  same resources in WorldCat became the role.  During the pilot, we learned that in some cases more was better because the top topic  might not make a lot of sense or the top role might not make a lot of sense just on a purely  statistical basis.  This is especially a problem with some folks who aren't traditional authors of works.  The score then is more complicated.  This was provided in the response to a search.  So if you got a result list back, entered a name into the service, got 10 results back,  one option was to rank those by a score.  And I'll show an example of that in a minute.  So what that is is basically imagine sort of a page rank type of thing.  So how interconnected is that person within WorldCat?  So we found that to be especially useful for some of the partial matches that we offered  via the service on the fuzzy matching.  So I was told that people wouldn't mind if I put up some JSON.  So I'm going to do that.  So this is a single result from a search.  So this search is simplified, but I could add parameters in terms of a result set of  one, 10.  So one of the results here, we get the entity ID.  We get a default label, birth date, role, topic, the scores I mentioned.  Scores, I saw scores from something like 40,000 down to two.  So there's a fairly wide range.  A particular note here are all the language labels that we have.  This was very intense processing to do this.  And it wasn't very neat, if I can explain that for just a minute.  So essentially what we wanted to do was allow for searches to be focused towards a specific  language.  Unfortunately, the connection between specific authority files and specific languages isn't  always neat.  So we had to make some educated guesses, in some cases, to distinguish between, say, British  English and American English.  Some authority files aren't dedicated to a specific language, and that makes things  a little bit more difficult.  But you can see here, I actually snipped the number of language labels here in brackets  there, got a little long.  But those would be things that you could search against.  Also during the pilot, we heard some requests for improving searching against some of these  different parameters.  So could I combine a name search with a language or something like that?  We didn't get there in our short timeframe.  We also had some interesting discussions around whether that would require re-indexing and  creating new indexes or whether we wanted to do that through more of a bundle of terms  type model.  Although we tried to make it an API-first model, we did also provide some demo web apps.  So the first type of demo web app we did basically used this type of response form to build sort  of a bento box type display of ranked results, prettifying and formatting some of the information  that you see here on the screen, and then obviously ranking those by the score.  And then upon clicking on one of those, you would get a nice display of that entity.  So just a really a mock-up here.  Well, not a mock-up, but this is a prototype that we developed and delivered during the  pilot.  What's interesting here is that you can see some of the information, the picture, the  little tagline Spanish painter and printmaker, and that extensive description are actually  not stored in the person entity.  They're just stored as links.  And then at render time, we're going out and grabbing that and then displaying it.  But you can see the alternate names are listed, same as relationships are listed.  And then something fun that we experimented with was grabbing the family relationships  out of WikiData.  I don't have a good example, but for some of those, we could actually link back to other  person entities.  So some lessons learned.  I have lessons learned sort of from the data aggregator view, from the service provider  view, and then from pilot activity participants type of view.  So the first just being that many sources are available.  No single source is good at everything.  Not naming names, but we found that some files would be really good at dates, and so we trusted  those.  But that file might be excellent in a specific language format, so we would trust that one  a little bit more.  So the quality does vary widely by element type.  So when we're talking about weighting, we're talking about preferring, we're talking about  adjusting, that's not at the source level, that's at that field per source level.  We also feel that data aggregation is crucial.  So a lot of the crunching that we did to try to improve search results really benefited  from the fact that we had all of this data in-house, we talked about is providing context  at scale.  So you can bring a lot of things to bear in terms of how important a person is within  the corpus, and then all the different ways that information about that person can be  provided.  When weighting and scoring are absolutely crucial, goes along with that scale.  So from the service consumers view, the first thing I wanted to mention was just that remembering  our workflows, remembering if I'm trying to enter information, a link for a person entity,  I need to have that context.  I need to have, if I'm searching for a John Smith, I got to find that right John Smith.  So having those roles, having those topics, having the dates available right there in  that first search result response is critical and useful.  Obviously context being key to names, as the victim of kind of a common name myself, I  feel this one deeply.  So there's a lot of John Chapman's in the database.  And then I mentioned a little bit earlier about the difference between possibly indexing  more terms versus having more terms piled in and available for search.  Indexing is expensive, and so that's something that we talked about a lot.  The language support, very important, but it is inexact, so we saw some edge cases that  maybe were not edge casey enough popping up.  The nice thing about language tagging would be things like, for example, if you know a  name is Chinese, you can go ahead and treat the honorifics in a specific way that you  need to do differently than if it's an English name.  So getting that right is great.  It's difficult to get that right in an automated fashion 100% of the time.  We also have an unsolved problem around sparse clusters.  So the person entity data follows a classic long tail model.  So we created something like 120 million person entities.  There's roughly 17 million of those that are really highly cross-linked that we can bring  a lot of this processing to bear.  A lot of the other stuff is one OCLC number, one name.  We don't know a lot else.  So something that people asked about during the pilot, and we, again, we didn't have time  to explore it more fully, but we can think of a lot of good ways to get there would  be how to get those clusters better integrated within the whole network.  The combined view then, if you can't find that entity, how can you create a new ID and  how will that work into an effective workflow?  So when you're minting IDs, any little bit of friction means that you slow that workflow  down very quickly.  We heard requests about, you know, can we enhance the service to create a new person entity?  So where do we go from here?  From an OCLC point of view, we want to continue starting and then ending these pilots and  experiments.  So have processed them quickly.  We want to move more from projects to production.  We relied heavily on VF, on ISNI, on WorldCat identities.  We're very interested in continuing to move those to some more sustainable and persistent  systems at an operational level.  We want to consider positive and negative incentives.  So what are the incentives to use particular identifiers and to participate in their enhancement,  especially in an environment where things are being clustered and matched?  Where is the biggest bang for the buck?  Where is the biggest return on investment in terms of correcting and enhancing metadata  within a vastly networked graph?  And then also, we need to surface that local expertise to build context.  So there are many pockets of specialized knowledge around the world.  Bringing those in brings yet another perspective, yet another angle to view things on.  So then in that bigger point of view, single aggregation is never going to be complete and  comprehensive.  We want to encourage some more focused experimentation in this way.  We're really happy with how we were able to iterate and improve the services that we provided.  And we'd like to continue to work together, whether it's VF, ISNI or WorldCat to better  represent these connections between bibliographic data and traditional authority data.  Lastly, I can take questions.  I also want to thank my colleagues who worked with me and helped out with the service, provided  the technical backbones, so Jeff Mixter, Steven Shindehedy and Bruce Washburn.  Thank you.  Thank you, John.  That was excellent.  So do we have questions for the speaker?  Yes.  Thank you.  Thank you very much for this talk, John.  To catch up your last sentence, let's continue to work together.  Because this was, as you mentioned, this was part of the second phase of this project,  and I gave you some feedback.  And I think it was quite positive feedback because, yes, I made some tests and it would  be very helpful for us to link our person entities against other repositories.  But I haven't heard anything since last February what's going on and how we could use your  person entity API.  So to be clear, we have a couple different versions, unfortunately, of person data.  So as I mentioned for the past two and a half, three years, we've been publishing WorldCat  entities.  For this pilot, what we did was essentially create an enhanced version of these person  entities and then provide access to them via the service.  In terms of moving the service into production along the way, we realized that many of the  systems that we rely on needed to be brought to a better production environment.  A lot of what I described is manual effort, semi-automated, and wasn't part of our main  production workflow.  So we are waiting to announce availability until we have this better supported and it  can commit to it as a sustainable project.  We know in the past, CLC has had services that have sort of an unclear status in terms  of whether they're experimental or production.  We don't want to do that again.  And that's one of the reasons why we had that firm stop date.  So.  Are there other questions?  Thank you.  On the user interface, I see the family relationship box.  And how do you build this box?  Are textual information or relations?  Real relation?  I'm afraid I don't understand the question.  On your slide, I see a box with family relation.  Oh, yes.  Okay.  On your slide.  And I would like to know if you create object properties with real relation between persons  or are only textual information to create this network?  So for that feature, what we were able to do is pull in data from WikiData for the display  here.  What we were also able to do as an experiment but not sort of fully within the databases,  if these names that were referred to, for example, if his father was represented by  a person entity, then we could also link, provide that as a link instead of just text.  That was a messy and not very successful experiment, so we didn't really roll that out.  Other questions?  Hi, John.  One of the things I've been interested in with things like VF, and I think it applies  to these computed personal identities as well, is how does one think about persistence in  this space?  So I can imagine seeing them as a lookup and then you find some other more managed identifier  like the ISNI which you record, but if there's a potential for the VF or the person entity  to change on a recomputation, how do you think about managing that in a persistent sense?  So we know that the drift in VF identifiers is a huge problem.  We wrestled with that in the project.  Our goal would be to provide person entity IDs that were persistent and sustainable and  linked to whatever they could when you resolved them.  As I mentioned, we don't want to roll something out that we're not fully behind in terms of  the IDs being persistent, so much of the work you've seen here is not production ready yet.  So I think that in order for the, I think this use case where at the ID level when you resolve  that ID, you get not just links but context is very powerful, so we want to do it right  and roll that out when it's ready.  This is a difficult question having to do with the read, write, web and closing the  loop of data.  Where do we report problems and do we have a sort of workflow for handling problems?  I'm right now looking at the page for Stephen Hawking and when it says his name is also  Jane Hawking scientist, I mean the primary name and a few other names that are maybe  his relatives but obviously not his own.  So is there some sort of workflow of reporting these errors back to the providers somehow?  So the errors that you mentioned if I understand them may be in the data providers or it may  be in our computation.  And so in terms of reporting errors, this is primarily, you know, we have email addresses  that, you know, support requests or record corrections can go to.  As a semi-production service, we would just route those to the right person.  Any other questions?  This may be something you can't really talk about in detail but given that you have really  large numbers of data sets to crunch, could you hint at the infrastructure you're using  for that?  Sure.  So the, again, I'm a product guy.  So at the database level, we're using Hadoop and HBase to build the entities.  And then in terms of the pilot and how the search was done against those entities, that's  an elastic search implementation.  And then our UI stack is Node.js and some Angular.js for some particular implementations.  In terms of the data processing though, it's multiple iterations through, first the authority  files and then through the bibliographic data, gathering IDs and then further steps of mapping  those building interlinks between them.  Again, possibly at the wrong conference because I can't explain it in more detail.  All right.  Thank you very much for that.  Yay.  Yeah.  We can clap again.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.  Thank you.
Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_0_1259.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_1260_1391.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_1392_1667.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_1668_1715.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_1716_1787.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_1788_2255.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_2256_2339.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_2340_2459.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_2460_2819.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_2820_2927.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_2928_2975.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_2976_3323.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_3324_3371.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_3372_3527.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_3528_8339.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_8340_16799.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_16800_27047.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_27048_30623.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_30624_30779.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_30780_33035.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_33036_33407.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_33408_34571.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_34572_34727.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_34728_34823.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_34824_35327.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_35328_35519.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_35520_35579.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_35580_38111.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_38112_38351.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_38352_38615.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_38616_39155.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_39156_39251.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_39252_39323.png Person_Entities__Lessons_learned_by_a_data_provide_0yKD1Lz4oGA_39324_39717.png
You walked around and traded business cards. You have new ideas to talk with people about. So the first talk after the break, we're now in the linking things session of the day. And I'm excited to introduce John Chapman. He is a senior product manager for metadata services at OCLC. He's helped lead product strategy and planning of OCLC's many exciting linked data projects on other product development. He'll be talking about person insties, lessons learned by a data provider. Hi everyone. My role at OCLC is that of, as was mentioned, a senior product manager in metadata services. As such, I'm responsible for cataloging applications. But I also care about the data, obviously, that those cataloging applications use. We saw an opportunity to try to learn more about the entities that we had created in house and see how we might be able to provide better access to those entities to leverage those within cataloging workflows. Over the past several years, we've released WorldCat works and WorldCat persons, which between them total more than 300 million separate entities. What we found, though, we sort of had this moment about we've created all these entities, but people aren't really using them as much as we would like. So we asked the question about how could we make it easier for people to use them instead of just having to find them through following links? So how could we index them? How could we provide services around them to improve that situation? So today I'll just be talking about essentially how we enhanced, provided the data, some of the lessons that we learned around that, and then how we see the discussion moving forward. So as I mentioned, the primary goal was to improve access to our entities via an API-first type model. What I mean by that is just that we didn't stress at the beginning providing any sort of UI for this. Especially as we started developing the strategy, we decided that most of the institutions that would be using it would be wanting to write their own tools, perhaps write their own UIs to consume that, so we didn't prioritize the creation of the UI. The two major workflow considerations that we wanted to work in, treat as use cases, were when you're creating metadata, how could you most easily find and refer to WorldCat person entities? And then we also wanted to work around some use cases about improving navigation affordances in terms of possibly knowledge cards, provide tools of that sort so that people could put those into a UI. We had a small group. The group included members of some institutions here in the audience. We had National Library of Poland, National Library of Germany, Cornell, Harvard, Library of Congress, National Library of Medicine in the U.S., Stanford, UC Davis, Pepperdine, and Drexel, as well as the Swiss Bib Organization that we heard from earlier today. The pilot that we ran against these person entities had a very short time frame. We did it basically in October to February. Then we had a sharp cutoff. We actually shut the service down after that time frame. I had two phases, the first one being sort of the same as identifier lookup, very simple. A second phase was much more involved and involved string matching for person names. We realized going into phase one that everybody really, really wanted the stuff in phase two, but we had to work towards that. We couldn't offer it all immediately. As I mentioned, phase one being a same-ass service. What we did here was we started with VF and what VF does of matching between the different authority files. We didn't take VF data, but we used the same algorithms and rebuilt it. We provided additional links based on anything we could find through analyzing, as I said, not only the VF corpus, but WorldCat. Some of the projects that some people might be familiar with, the WorldCat entities, using some of the strategies that we learned there. This is basically an ID to ID matching. The request that went into the service would have to include a known identifier. Then for matchback, you would get our person entity URI, which you can find down here in the list somewhere, as well as all the other matching URIs. Something to note here, in the pilot, we allowed discussion about the difference between authority data and person data, the difference between modeling, collection of names versus modeling information about a person. Note here in the list that we have several examples of URIs that refer to this person as a topic, so not just a name reference. Phase two, as I mentioned, much more involved. This included a text-based search. The data stored in the entity included a lot more. We started storing a preferred name or preferred names in a bunch of different name forms, including language tags. Also important here to note is that we provided things that we called roles, topics, and also provided a score. Roles and topics were determined going against bibliographic data, so essentially the most prevalent subject headings among the bibliographic entities that the person was associated with. That became the topic. And then the most prevalent role that that person has been assigned in terms of those same resources in WorldCat became the role. During the pilot, we learned that in some cases more was better because the top topic might not make a lot of sense or the top role might not make a lot of sense just on a purely statistical basis. This is especially a problem with some folks who aren't traditional authors of works. The score then is more complicated. This was provided in the response to a search. So if you got a result list back, entered a name into the service, got 10 results back, one option was to rank those by a score. And I'll show an example of that in a minute. So what that is is basically imagine sort of a page rank type of thing. So how interconnected is that person within WorldCat? So we found that to be especially useful for some of the partial matches that we offered via the service on the fuzzy matching. So I was told that people wouldn't mind if I put up some JSON. So I'm going to do that. So this is a single result from a search. So this search is simplified, but I could add parameters in terms of a result set of one, 10. So one of the results here, we get the entity ID. We get a default label, birth date, role, topic, the scores I mentioned. Scores, I saw scores from something like 40,000 down to two. So there's a fairly wide range. A particular note here are all the language labels that we have. This was very intense processing to do this. And it wasn't very neat, if I can explain that for just a minute. So essentially what we wanted to do was allow for searches to be focused towards a specific language. Unfortunately, the connection between specific authority files and specific languages isn't always neat. So we had to make some educated guesses, in some cases, to distinguish between, say, British English and American English. Some authority files aren't dedicated to a specific language, and that makes things a little bit more difficult. But you can see here, I actually snipped the number of language labels here in brackets there, got a little long. But those would be things that you could search against. Also during the pilot, we heard some requests for improving searching against some of these different parameters. So could I combine a name search with a language or something like that? We didn't get there in our short timeframe. We also had some interesting discussions around whether that would require re-indexing and creating new indexes or whether we wanted to do that through more of a bundle of terms type model. Although we tried to make it an API-first model, we did also provide some demo web apps. So the first type of demo web app we did basically used this type of response form to build sort of a bento box type display of ranked results, prettifying and formatting some of the information that you see here on the screen, and then obviously ranking those by the score. And then upon clicking on one of those, you would get a nice display of that entity. So just a really a mock-up here. Well, not a mock-up, but this is a prototype that we developed and delivered during the pilot. What's interesting here is that you can see some of the information, the picture, the little tagline Spanish painter and printmaker, and that extensive description are actually not stored in the person entity. They're just stored as links. And then at render time, we're going out and grabbing that and then displaying it. But you can see the alternate names are listed, same as relationships are listed. And then something fun that we experimented with was grabbing the family relationships out of WikiData. I don't have a good example, but for some of those, we could actually link back to other person entities. So some lessons learned. I have lessons learned sort of from the data aggregator view, from the service provider view, and then from pilot activity participants type of view. So the first just being that many sources are available. No single source is good at everything. Not naming names, but we found that some files would be really good at dates, and so we trusted those. But that file might be excellent in a specific language format, so we would trust that one a little bit more. So the quality does vary widely by element type. So when we're talking about weighting, we're talking about preferring, we're talking about adjusting, that's not at the source level, that's at that field per source level. We also feel that data aggregation is crucial. So a lot of the crunching that we did to try to improve search results really benefited from the fact that we had all of this data in-house, we talked about is providing context at scale. So you can bring a lot of things to bear in terms of how important a person is within the corpus, and then all the different ways that information about that person can be provided. When weighting and scoring are absolutely crucial, goes along with that scale. So from the service consumers view, the first thing I wanted to mention was just that remembering our workflows, remembering if I'm trying to enter information, a link for a person entity, I need to have that context. I need to have, if I'm searching for a John Smith, I got to find that right John Smith. So having those roles, having those topics, having the dates available right there in that first search result response is critical and useful. Obviously context being key to names, as the victim of kind of a common name myself, I feel this one deeply. So there's a lot of John Chapman's in the database. And then I mentioned a little bit earlier about the difference between possibly indexing more terms versus having more terms piled in and available for search. Indexing is expensive, and so that's something that we talked about a lot. The language support, very important, but it is inexact, so we saw some edge cases that maybe were not edge casey enough popping up. The nice thing about language tagging would be things like, for example, if you know a name is Chinese, you can go ahead and treat the honorifics in a specific way that you need to do differently than if it's an English name. So getting that right is great. It's difficult to get that right in an automated fashion 100% of the time. We also have an unsolved problem around sparse clusters. So the person entity data follows a classic long tail model. So we created something like 120 million person entities. There's roughly 17 million of those that are really highly cross-linked that we can bring a lot of this processing to bear. A lot of the other stuff is one OCLC number, one name. We don't know a lot else. So something that people asked about during the pilot, and we, again, we didn't have time to explore it more fully, but we can think of a lot of good ways to get there would be how to get those clusters better integrated within the whole network. The combined view then, if you can't find that entity, how can you create a new ID and how will that work into an effective workflow? So when you're minting IDs, any little bit of friction means that you slow that workflow down very quickly. We heard requests about, you know, can we enhance the service to create a new person entity? So where do we go from here? From an OCLC point of view, we want to continue starting and then ending these pilots and experiments. So have processed them quickly. We want to move more from projects to production. We relied heavily on VF, on ISNI, on WorldCat identities. We're very interested in continuing to move those to some more sustainable and persistent systems at an operational level. We want to consider positive and negative incentives. So what are the incentives to use particular identifiers and to participate in their enhancement, especially in an environment where things are being clustered and matched? Where is the biggest bang for the buck? Where is the biggest return on investment in terms of correcting and enhancing metadata within a vastly networked graph? And then also, we need to surface that local expertise to build context. So there are many pockets of specialized knowledge around the world. Bringing those in brings yet another perspective, yet another angle to view things on. So then in that bigger point of view, single aggregation is never going to be complete and comprehensive. We want to encourage some more focused experimentation in this way. We're really happy with how we were able to iterate and improve the services that we provided. And we'd like to continue to work together, whether it's VF, ISNI or WorldCat to better represent these connections between bibliographic data and traditional authority data. Lastly, I can take questions. I also want to thank my colleagues who worked with me and helped out with the service, provided the technical backbones, so Jeff Mixter, Steven Shindehedy and Bruce Washburn. Thank you. Thank you, John. That was excellent. So do we have questions for the speaker? Yes. Thank you. Thank you very much for this talk, John. To catch up your last sentence, let's continue to work together. Because this was, as you mentioned, this was part of the second phase of this project, and I gave you some feedback. And I think it was quite positive feedback because, yes, I made some tests and it would be very helpful for us to link our person entities against other repositories. But I haven't heard anything since last February what's going on and how we could use your person entity API. So to be clear, we have a couple different versions, unfortunately, of person data. So as I mentioned for the past two and a half, three years, we've been publishing WorldCat entities. For this pilot, what we did was essentially create an enhanced version of these person entities and then provide access to them via the service. In terms of moving the service into production along the way, we realized that many of the systems that we rely on needed to be brought to a better production environment. A lot of what I described is manual effort, semi-automated, and wasn't part of our main production workflow. So we are waiting to announce availability until we have this better supported and it can commit to it as a sustainable project. We know in the past, CLC has had services that have sort of an unclear status in terms of whether they're experimental or production. We don't want to do that again. And that's one of the reasons why we had that firm stop date. So. Are there other questions? Thank you. On the user interface, I see the family relationship box. And how do you build this box? Are textual information or relations? Real relation? I'm afraid I don't understand the question. On your slide, I see a box with family relation. Oh, yes. Okay. On your slide. And I would like to know if you create object properties with real relation between persons or are only textual information to create this network? So for that feature, what we were able to do is pull in data from WikiData for the display here. What we were also able to do as an experiment but not sort of fully within the databases, if these names that were referred to, for example, if his father was represented by a person entity, then we could also link, provide that as a link instead of just text. That was a messy and not very successful experiment, so we didn't really roll that out. Other questions? Hi, John. One of the things I've been interested in with things like VF, and I think it applies to these computed personal identities as well, is how does one think about persistence in this space? So I can imagine seeing them as a lookup and then you find some other more managed identifier like the ISNI which you record, but if there's a potential for the VF or the person entity to change on a recomputation, how do you think about managing that in a persistent sense? So we know that the drift in VF identifiers is a huge problem. We wrestled with that in the project. Our goal would be to provide person entity IDs that were persistent and sustainable and linked to whatever they could when you resolved them. As I mentioned, we don't want to roll something out that we're not fully behind in terms of the IDs being persistent, so much of the work you've seen here is not production ready yet. So I think that in order for the, I think this use case where at the ID level when you resolve that ID, you get not just links but context is very powerful, so we want to do it right and roll that out when it's ready. This is a difficult question having to do with the read, write, web and closing the loop of data. Where do we report problems and do we have a sort of workflow for handling problems? I'm right now looking at the page for Stephen Hawking and when it says his name is also Jane Hawking scientist, I mean the primary name and a few other names that are maybe his relatives but obviously not his own. So is there some sort of workflow of reporting these errors back to the providers somehow? So the errors that you mentioned if I understand them may be in the data providers or it may be in our computation. And so in terms of reporting errors, this is primarily, you know, we have email addresses that, you know, support requests or record corrections can go to. As a semi-production service, we would just route those to the right person. Any other questions? This may be something you can't really talk about in detail but given that you have really large numbers of data sets to crunch, could you hint at the infrastructure you're using for that? Sure. So the, again, I'm a product guy. So at the database level, we're using Hadoop and HBase to build the entities. And then in terms of the pilot and how the search was done against those entities, that's an elastic search implementation. And then our UI stack is Node.js and some Angular.js for some particular implementations. In terms of the data processing though, it's multiple iterations through, first the authority files and then through the bibliographic data, gathering IDs and then further steps of mapping those building interlinks between them. Again, possibly at the wrong conference because I can't explain it in more detail. All right. Thank you very much for that. Yay. Yeah. We can clap again. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.
OCLC's many exciting linked data projects on better access to those entities to leverage those several years, we've released WorldCat works and WorldCat persons, which between them total more than 300 million separate entities. What we mentioned, the primary goal was to improve access the beginning providing any sort of UI for this. would be using it would be wanting to write their you're creating metadata, how could you most Pepperdine, and Drexel, as well as the Swiss Bib The pilot that we ran against these person that some people might be familiar with, the more complicated. This was provided in the always neat. So we had to make some educated sparse clusters. So the person entity data lot of this processing to bear. A lot of the other stuff is one OCLC number, one name. We didn't have time to explore it more fully, but we you create a new ID and how will that work into improve the services that we provided. And we'd connections between bibliographic data and together. Because this was, as you mentioned, project. Our goal would be to provide person and linked to whatever they could when you understand them may be in the data providers or numbers of data sets to crunch, could you hint at the authority files and then through the