Author items in Wikidata
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Cobb, Simon
Data quality, disambiguation, profiles, persistent identifiers, etc.
 Hello, welcome back to the author items session at this wiki site conference. So before I introduce Simon, the first speaker today, I just want to remind everyone that this event is covered by the Wikimedia Foundation friendly space policy. So you can see the link at the bottom there if you want to find out more about that, but please just be aware that this is a friendly space, be nice to everyone and follow that policy. Now then, I want to introduce the first speaker, which is Simon Cobb, and I've known Simon now for, gosh, probably going on for five years. He first approached us at the National Library and asked if he could help. He was interested in wiki data and Wikimedia and he wanted to see if he could help out in any way. He went on to become our wiki data visiting scholar, the first position of its type in the world as far as we're aware. And Simon's done some fantastic work, not just with bibliographic data, but all sorts of different collections, sharing them on wiki data, developing the way that those are modelled. And most recently he did a huge amount of work getting over 30,000 books from the National Library of Wales collections onto wiki data and really working hard on author disambiguation and getting all the publishers connected. So I'm really looking forward to hearing Simon's talk, so I will now hand you over to Simon. Hi everyone. So I'm going to talk about author items in wiki data for the next few minutes. As Jason said, I've been doing a lot of work over the last few years with bibliographic data and what I want to do in this presentation is highlight some of the issues that I'm aware of about data quality concerning author items. I want to share knowledge about how we can import more data from ORCID and primarily what I want to do is start a conversation about author items, the data quality and what we want to do with them really. We're just creating a lot of author items at the moment but I don't think we've given sufficient thought to a strategy for how we're doing it and how we're improving and maintaining that data. So that's something that is a theme that runs through this whole presentation. So just to set the scope, this is focusing on author items who have an ORCID ID. We've got about 1.6 million of these in wiki data now. I've done some analysis to prepare my presentation and I also wrote a paper which is available on Commons which I'm effectively presenting now but there are a few differences. I've done some analysis of a 10% sample of these author items and that was done using checksum beginning with 0 and then two following digits or an X from ORCID IDs which I have then compared data from wiki data and ORCID and I'm going to talk about some of the findings of that analysis now. So the first thing I want to talk about is the properties that are used on author items. I've just identified a list of properties which are likely to be found on humans and we might expect people who are actively publishing scholarly articles to have these properties on their wiki data item and it becomes apparent quite quickly that we don't have very much data about these authors. In some cases it's understandable because we don't know that much about them but in other cases it's just the items are sparse because they haven't been worked on. A really good example of this is the names, the family name and the given name of the authors. We have what just over a quarter of the items have a given name, less than 10% have a family name. This data seems to me to be readily available either from publications or from their ORCID. So it seems inexcusable that we've got such low coverage of it in these properties. There are other things that we should really have. I feel quite strongly that we need to have better affiliation data because it's just so important for any further analysis of author items or their publications. The author acts as a node between a publication and their institution. So if you want to study the research for an institution you tend to need the affiliation data to be on an author item. This is not a secret. This data can be gleaned from publications or from other databases such as ORCID which we know is linked to all of these items. So the fact that we've only got a little over a quarter of all of our author items have an employer, well most of them will be doing work in the context of their employment. So I would argue this should be closer to 100%. Although I don't think we can ever achieve completeness I would say. There's other things like language spoken and written or field of work. I would have thought that for researchers we need to focus on improving our coverage of these properties. Both less than 1% of the items studied have those properties. I just think this is quite low across the board and we really need to work on it. If anyone saw Daniel's presentation about the state of Wicked data earlier I'm very mindful of what he's saying about avoiding thinking about how big the challenge is. I think that's really shrewd but I also think we have to keep on taking steps to improve what we have and think about where we're going with this rather than just creating items and hoping to get improved later. So this is quite interesting. It's showing the number of statements on average over time so as we move from left to right you notice it drops off towards the newer items. Obviously the old items have existed for longer and they've had more time to attract curatorial efforts of the editor's community. But nevertheless we have over the last year we've created something like 110,000 new author items just in this sample data and they all have around four and a half statements on average per item which is really too low and should also state that it's not clear from this chart but the last quarter it represents about two thirds of the total number of items so it's really quite a sizable problem that we're creating very sparse author items and they're not receiving the efforts of editors to improve them for a long time. I think that makes it quite difficult to use them because well people might be interested in doing curation for their institution or subject based editing without having sufficient data in the author items you can't really identify a subset to work with. So it becomes a very manual process unless we can start importing data to improve these items in bulk editing processes. We also, I want to draw attention to what I think is a nonsensical equation. We've got occupation equals researcher times 1.66 million. I don't think we should be adding that everyone who has an orchid is a researcher. The screenshot shows my wiki data item. I can tell you I'm not a researcher but I do have an orchid and that's because I contribute to publications. We have to bear in mind that orchid isn't just for search it's open researcher and contributor ID and we've ended up with a lot of garbage. We don't have occupations that we can query and identify what sort of work people are doing. We're a researcher and we could infer that from the orchid if that were true anyway. This is just an example of large scale creation of what I consider pretty useless data. That's a personal opinion and you're very welcome to disagree with that. Let me know what you think. I'd be really curious to know whether anyone thinks that's useful to have. So moving on, this is an example of some incorrect data that's been imported. At a glance you might see quite a number of things that are wrong with it. It's actually the wiki data item for Anton Bernard that was incorrectly labelled as Differential Society for Pediatric Hematology and Immunology for 10 months after creation. It had that label despite having an orchid, despite being an instance of a human and having occupation as researcher. It's just incompatible to have that label with those properties and nevertheless it's just persisted for 10 months. Until I noticed it I did rectify it but it's quite difficult because you have to then go back through the publications that are linked to and start picking what the actual affiliation is or whether you need to split the item. It becomes quite time consuming and I think it's indicative of mass data imports without sufficient validation taking place. I'm regularly editing orchids that have been imported that aren't consistent with the format regular expression so they can be in correct lengths, they can have just completely incompatible formatting for working orchids. I just don't really think this is good enough. I'm hoping this resonates with other people and we can start discussing how to avoid these issues. Obviously there's a lot of data linked from Wicked Data by virtue of having orchid IDs and we can start importing that data and improving the situation. The problem is when we want to import affiliation data so that's employment or the place of education for the owner of the orchid profile. We have to first go through a process of reconciliation to match what organisations are stored in orchid with Wicked Data. This is fine where we've got persistent identifiers that we can use to unambiguously make that connection. However, unfortunately, we don't always have the identifiers in Wicked Data and it's particularly a problem because Ringold identifiers are so widely used in orchid that we have less than half of them seem to be in Wicked Data. There's something approaching half a million in orchid and something like 65,000 in Wicked Data that are attached to organisations. Without those connections between the persistent identifier and the Wicked Data item, it becomes very difficult to reconcile successfully because orchid and Wicked Data are both using multilingual affiliations and there's a myriad of different name formats you can use for any one organisation anyway. Trying to reconcile using just a text is very, very challenging. I haven't discovered a viable way of traversing from a subunit of an organisation to the parent if the subunit doesn't exist. For example, if I was trying to reconcile a faculty which isn't in Wicked Data, it's very difficult to then go to the university which probably is. There's no connections in orchid or they're generally lacking in Wicked Data to do that traversal. So, just end up not being able to import that data and we can't reconcile it. Whereas if you could go to the university and use that for the subunits, you would be able to start adding affiliations and potentially then improve it later. But unfortunately, that doesn't seem to be an option at the moment. I just wanted to comment as well on the distribution of the persistent identifiers that we have in Wicked Data. If we rely solely on what we have already, we're going to be importing a lot of data about a few countries really. We're going to be connecting authors in USA, in Britain and a few other countries in particular. I'm just a little bit concerned this could introduce biases or reinforce biases that we already have. We need to improve this distribution to get better worldwide coverage of affiliation data into Wicked Data. It's going off topic slightly because this will get into a need to curate data around institutions. But that is a prerequisite. I've been able to add affiliation data to authors. Anyway, I think that's enough said about that. I think it's something we should be mindful of. So additional problems which make reconciliation and data imports challenging. In Wicked Data, we've obviously got an incomplete dataset. We don't have all the institutions and their components. Further, we don't have all of the roles that a researcher or anyone working related to research publications could be in. We don't have all the academic ranks. We don't have all the degrees. So these are all things that you can't reconcile and import that data because we don't have it. I don't really know where we go with that. It's a big challenge. But it does limit the amount of data that we can import. We also have some errors in Wicked Data. I think there will always be errors in Wicked Data, but we need to be aware that there are identifiers linked to the wrong institution. For example, if an ISNI is linked to the wrong institution, it can lead to the Ringgold being linked to the wrong institution, which can then cause data imports to be incorrect. So you can end up with a chain of errors that, unless they're addressed, they will just carry on creating more and more errors as we go along. That's obviously a problem. It does get picked up. People every now and again send me a message and say you've done some incorrect data imports. It's great that people do that. If you have, thank you. Not only does it highlight errors in my own work, it enables me to identify what's causing those errors and prevent them from happening again. Another challenge or another conversation, perhaps, is around how we store deprecated identifiers in Wicked Data. So if an identifier is withdrawn or redirected, I think we need to be consistent in how we're handling those so that we can still reconcile against them and import data. The worst thing we can do is just delete them. We need to retain them, but it's probably just need some consensus on whether we're storing them as preferred rank, deprecated rank, or just to know what we're doing, do it consistently. There are also problems in ORCID, which cause challenges when we're trying to import data. The example shown is, I would say, excessively granular. They have eight different entries for one continuous spell of employment at the same institution. If we were to import this to Wicked Data, I don't think we could assign any role that rarely differentiates between them. So there needs to be some sort of consensus around how we handle things like this, whether we just roll all of this up into one, or whether we do want that granularity. I have to admit I've been a bit inconsistent in how I've dealt with this when I've been doing data imports. And that is just purely because I don't know what the best way to do this is. So that's really something that I think needs some discussion and we need to put a bit of thought into that. There are also errors in ORCID that someone recently highlighted. This one, to me, they said, when I got a message there in a batch of my imported data was wrong, it turned out that it's because the ring gold hold for the University of San Paolo in ORCID. In this ORCID is incorrect, so it ends up causing reconciliation to the wrong institution which causes data to be imported incorrectly. It's not a big problem that I'm aware of in ORCID, but it does happen. It's just, again, something to be mindful of. Okay, and the final one that I wanted to highlight is in the education record where people are compressing two degrees into one entry. It's very challenging to work with because you need to decide whether you're going to try and split that out or you're going to try and split it, reconcile two degrees and import it or just quite a few different ways that you could handle this. Usually it just ends up being things that don't get imported at the moment because there's a lot more low hanging fruit to take, so why work on the difficult stuff when there's easier things, it's been my thinking. But at some point we are going to need to tackle this if we want to import this data. So I'm suggesting a few next steps of where we might go with this. Again, this is really to try and start a conversation. I'm not saying we have to do it this way. If you disagree, the best thing to do is say so because that will contribute to the conversation and we can reach some sort of consensus. I think we really need to consider what is the minimal acceptable standard for author item data. I really question whether some of the imports that are happening on mass at the moment are creating data that's good enough quality and whether with small improvements we could make quite a big improvement to data quality. Sorry, that small improvements to the import methodology could make quite big improvements to the data quality. I think to help decide whether the standard is good enough, we need to define requirements for different use cases. What are we actually doing with author items? Are we just creating them because we can? Are we creating them just as a node to link different publications? Or do we want to do other things with them as well? When we know that we can start looking at what data is needed for those different use cases. Some of the other things are just relating to persistent identifiers. I won't go into those in detail. I'm currently going through a process of validating my own data imports and trying to identify problems. It's very difficult to do that because I haven't stored in the references to put code from orchids so we have to import the entire set of employment or education summaries rather than being able to link directly to a specific summary. Which leads to, I think there's a need to start storing the put codes in references in wiki data when we're importing data from orchids so we can validate it in the future, check for updates, etc. What I really want to do, kind of my motivation behind organizing this whole session, is to work towards setting up an online workshop so we can actually have discussions and we can work out how to collaborate around author items. I know there are other people who are working on improving data quality but we're all quite disjointed so it would be really good to get interested people together and have a conversation, think about how we can work collaboratively for the overall good of improving data quality. So that's a summary of what I'm thinking and what I've been working on so I'm happy to take any questions or very interested in other people's comments on this topic as well. Brilliant, thank you very much for that. Simon, that was really interesting and yes we do have a few minutes for questions. There are some in the etherpad already but if you have any others and you want to ask them just pop those in as soon as possible and I'll try and ask Simon. So the first question we've got for Simon is, is it possible to do a mix and match between orchids and viath? Well, mix and match is a tool for importing data to wiki data so not directly I don't think, you'd have to import data about one to wiki data and then import the other based on wiki data so probably yes. I guess wiki data is kind of a mix and match in a way isn't it? Yeah, it is but not as easy as it's made to sound like. Cool, there's a comment question. Someone's a bit worried that wiki data items with orchid IDs might be linked to the wrong people or incorrectly listed as an author on an item about an article for example. So do you come across these kind of errors? What are your thoughts on this? Yeah, I mean I highlighted one in that presentation which was a glaring error where it was clearly an organisation that had been created and that was, I believe that happened because the wrong author in a list of authors on a publication was scraped and imported and associated with the orchid ID. So yes, it does happen. I think there's a serious need for doing data validation across all the scholarly articles and these mass data imports that haven't been touched by human editors because yes, there will be errors, it's inevitable but I have no idea how big a problem that would be. Okay, thank you. The question is, do you have any thoughts on using DBLP as a preferred identifier with a fallback to orchid? That makes sense? Yeah, it does make sense. I don't know why you'd use it as a preferred identifier. I'll use it as an extra identifier on top of orchid and probably fall back to DBLP rather than give way round. That's a personal preference I suppose. Just to elaborate on that slightly, I would say because orchid is curated by the author, it's an unusually reliable source although obviously times when that could be a problem but in general it's probably the best source of data we have for author items and then afterwards we should start looking at other sources where orchid isn't helpful. Fantastic. I think that's about it for questions. Apologies if you have posted a question somewhere and we haven't seen it but I'm sure Simon will be happy to take questions on Telegram or anywhere else during the afternoon. Yeah, very much so. We've got a break later on so if any questions emerge you can potentially take them later or just general questions that can come up during the afternoon or if you have a question you think of it later just send me a message on Wicked Data. I'm on there all the time so we'll know you'll be fine quite quickly.
 Hello, welcome back to the author items session at this wiki site conference.  So before I introduce Simon, the first speaker today, I just want to remind everyone that  this event is covered by the Wikimedia Foundation friendly space policy.  So you can see the link at the bottom there if you want to find out more about that, but  please just be aware that this is a friendly space, be nice to everyone and follow that  policy.  Now then, I want to introduce the first speaker, which is Simon Cobb, and I've known Simon  now for, gosh, probably going on for five years.  He first approached us at the National Library and asked if he could help.  He was interested in wiki data and Wikimedia and he wanted to see if he could help out  in any way.  He went on to become our wiki data visiting scholar, the first position of its type in  the world as far as we're aware.  And Simon's done some fantastic work, not just with bibliographic data, but all sorts of  different collections, sharing them on wiki data, developing the way that those are modelled.  And most recently he did a huge amount of work getting over 30,000 books from the National  Library of Wales collections onto wiki data and really working hard on author disambiguation  and getting all the publishers connected.  So I'm really looking forward to hearing Simon's talk, so I will now hand you over to Simon.  Hi everyone.  So I'm going to talk about author items in wiki data for the next few minutes.  As Jason said, I've been doing a lot of work over the last few years with bibliographic  data and what I want to do in this presentation is highlight some of the issues that I'm aware  of about data quality concerning author items.  I want to share knowledge about how we can import more data from ORCID and primarily what  I want to do is start a conversation about author items, the data quality and what we  want to do with them really.  We're just creating a lot of author items at the moment but I don't think we've given  sufficient thought to a strategy for how we're doing it and how we're improving and maintaining  that data.  So that's something that is a theme that runs through this whole presentation.  So just to set the scope, this is focusing on author items who have an ORCID ID.  We've got about 1.6 million of these in wiki data now.  I've done some analysis to prepare my presentation and I also wrote a paper which is available  on Commons which I'm effectively presenting now but there are a few differences.  I've done some analysis of a 10% sample of these author items and that was done using  checksum beginning with 0 and then two following digits or an X from ORCID IDs which I have  then compared data from wiki data and ORCID and I'm going to talk about some of the findings  of that analysis now.  So the first thing I want to talk about is the properties that are used on author items.  I've just identified a list of properties which are likely to be found on humans and  we might expect people who are actively publishing scholarly articles to have these properties  on their wiki data item and it becomes apparent quite quickly that we don't have very much  data about these authors.  In some cases it's understandable because we don't know that much about them but in other  cases it's just the items are sparse because they haven't been worked on.  A really good example of this is the names, the family name and the given name of the  authors.  We have what just over a quarter of the items have a given name, less than 10% have a family  name.  This data seems to me to be readily available either from publications or from their ORCID.  So it seems inexcusable that we've got such low coverage of it in these properties.  There are other things that we should really have.  I feel quite strongly that we need to have better affiliation data because it's just  so important for any further analysis of author items or their publications.  The author acts as a node between a publication and their institution.  So if you want to study the research for an institution you tend to need the affiliation  data to be on an author item.  This is not a secret.  This data can be gleaned from publications or from other databases such as ORCID which  we know is linked to all of these items.  So the fact that we've only got a little over a quarter of all of our author items have  an employer, well most of them will be doing work in the context of their employment.  So I would argue this should be closer to 100%.  Although I don't think we can ever achieve completeness I would say.  There's other things like language spoken and written or field of work.  I would have thought that for researchers we need to focus on improving our coverage  of these properties.  Both less than 1% of the items studied have those properties.  I just think this is quite low across the board and we really need to work on it.  If anyone saw Daniel's presentation about the state of Wicked data earlier I'm very  mindful of what he's saying about avoiding thinking about how big the challenge is.  I think that's really shrewd but I also think we have to keep on taking steps to improve  what we have and think about where we're going with this rather than just creating  items and hoping to get improved later.  So this is quite interesting.  It's showing the number of statements on average over time so as we move from left to right  you notice it drops off towards the newer items.  Obviously the old items have existed for longer and they've had more time to attract  curatorial efforts of the editor's community.  But nevertheless we have over the last year we've created something like 110,000 new author  items just in this sample data and they all have around four and a half statements on  average per item which is really too low and should also state that it's not clear from  this chart but the last quarter it represents about two thirds of the total number of items  so it's really quite a sizable problem that we're creating very sparse author items and  they're not receiving the efforts of editors to improve them for a long time.  I think that makes it quite difficult to use them because well people might be interested  in doing curation for their institution or subject based editing without having sufficient  data in the author items you can't really identify a subset to work with.  So it becomes a very manual process unless we can start importing data to improve these  items in bulk editing processes.  We also, I want to draw attention to what I think is a nonsensical equation.  We've got occupation equals researcher times 1.66 million.  I don't think we should be adding that everyone who has an orchid is a researcher.  The screenshot shows my wiki data item.  I can tell you I'm not a researcher but I do have an orchid and that's because I contribute  to publications.  We have to bear in mind that orchid isn't just for search it's open researcher and contributor  ID and we've ended up with a lot of garbage.  We don't have occupations that we can query and identify what sort of work people are  doing.  We're a researcher and we could infer that from the orchid if that were true anyway.  This is just an example of large scale creation of what I consider pretty useless data.  That's a personal opinion and you're very welcome to disagree with that.  Let me know what you think.  I'd be really curious to know whether anyone thinks that's useful to have.  So moving on, this is an example of some incorrect data that's been imported.  At a glance you might see quite a number of things that are wrong with it.  It's actually the wiki data item for Anton Bernard that was incorrectly labelled as Differential  Society for Pediatric Hematology and Immunology for 10 months after creation.  It had that label despite having an orchid, despite being an instance of a human and having  occupation as researcher.  It's just incompatible to have that label with those properties and nevertheless it's  just persisted for 10 months.  Until I noticed it I did rectify it but it's quite difficult because you have to then go  back through the publications that are linked to and start picking what the actual affiliation  is or whether you need to split the item.  It becomes quite time consuming and I think it's indicative of mass data imports without  sufficient validation taking place.  I'm regularly editing orchids that have been imported that aren't consistent with the format  regular expression so they can be in correct lengths, they can have just completely incompatible  formatting for working orchids.  I just don't really think this is good enough.  I'm hoping this resonates with other people and we can start discussing how to avoid these  issues.  Obviously there's a lot of data linked from Wicked Data by virtue of having orchid IDs  and we can start importing that data and improving the situation.  The problem is when we want to import affiliation data so that's employment or the place of  education for the owner of the orchid profile.  We have to first go through a process of reconciliation to match what organisations are stored in orchid  with Wicked Data.  This is fine where we've got persistent identifiers that we can use to unambiguously make that  connection.  However, unfortunately, we don't always have the identifiers in Wicked Data and it's particularly  a problem because Ringold identifiers are so widely used in orchid that we have less than  half of them seem to be in Wicked Data.  There's something approaching half a million in orchid and something like 65,000 in Wicked  Data that are attached to organisations.  Without those connections between the persistent identifier and the Wicked Data item, it becomes  very difficult to reconcile successfully because orchid and Wicked Data are both using multilingual  affiliations and there's a myriad of different name formats you can use for any one organisation  anyway.  Trying to reconcile using just a text is very, very challenging.  I haven't discovered a viable way of traversing from a subunit of an organisation to the parent  if the subunit doesn't exist.  For example, if I was trying to reconcile a faculty which isn't in Wicked Data, it's  very difficult to then go to the university which probably is.  There's no connections in orchid or they're generally lacking in Wicked Data to do that  traversal.  So, just end up not being able to import that data and we can't reconcile it.  Whereas if you could go to the university and use that for the subunits, you would be  able to start adding affiliations and potentially then improve it later.  But unfortunately, that doesn't seem to be an option at the moment.  I just wanted to comment as well on the distribution of the persistent identifiers that we have  in Wicked Data.  If we rely solely on what we have already, we're going to be importing a lot of data  about a few countries really.  We're going to be connecting authors in USA, in Britain and a few other countries in particular.  I'm just a little bit concerned this could introduce biases or reinforce biases that  we already have.  We need to improve this distribution to get better worldwide coverage of affiliation data  into Wicked Data.  It's going off topic slightly because this will get into a need to curate data around  institutions.  But that is a prerequisite.  I've been able to add affiliation data to authors.  Anyway, I think that's enough said about that.  I think it's something we should be mindful of.  So additional problems which make reconciliation and data imports challenging.  In Wicked Data, we've obviously got an incomplete dataset.  We don't have all the institutions and their components.  Further, we don't have all of the roles that a researcher or anyone working related to  research publications could be in.  We don't have all the academic ranks.  We don't have all the degrees.  So these are all things that you can't reconcile and import that data because we don't have  it.  I don't really know where we go with that.  It's a big challenge.  But it does limit the amount of data that we can import.  We also have some errors in Wicked Data.  I think there will always be errors in Wicked Data, but we need to be aware that there are  identifiers linked to the wrong institution.  For example, if an ISNI is linked to the wrong institution, it can lead to the Ringgold  being linked to the wrong institution, which can then cause data imports to be incorrect.  So you can end up with a chain of errors that, unless they're addressed, they will just carry  on creating more and more errors as we go along.  That's obviously a problem.  It does get picked up.  People every now and again send me a message and say you've done some incorrect data imports.  It's great that people do that.  If you have, thank you.  Not only does it highlight errors in my own work, it enables me to identify what's causing  those errors and prevent them from happening again.  Another challenge or another conversation, perhaps, is around how we store deprecated  identifiers in Wicked Data.  So if an identifier is withdrawn or redirected, I think we need to be consistent in how we're  handling those so that we can still reconcile against them and import data.  The worst thing we can do is just delete them.  We need to retain them, but it's probably just need some consensus on whether we're  storing them as preferred rank, deprecated rank, or just to know what we're doing, do  it consistently.  There are also problems in ORCID, which cause challenges when we're trying to import data.  The example shown is, I would say, excessively granular.  They have eight different entries for one continuous spell of employment at the same institution.  If we were to import this to Wicked Data, I don't think we could assign any role that  rarely differentiates between them.  So there needs to be some sort of consensus around how we handle things like this, whether  we just roll all of this up into one, or whether we do want that granularity.  I have to admit I've been a bit inconsistent in how I've dealt with this when I've been  doing data imports.  And that is just purely because I don't know what the best way to do this is.  So that's really something that I think needs some discussion and we need to put a bit of  thought into that.  There are also errors in ORCID that someone recently highlighted.  This one, to me, they said, when I got a message there in a batch of my imported data was wrong,  it turned out that it's because the ring gold hold for the University of San Paolo in ORCID.  In this ORCID is incorrect, so it ends up causing reconciliation to the wrong institution  which causes data to be imported incorrectly.  It's not a big problem that I'm aware of in ORCID, but it does happen.  It's just, again, something to be mindful of.  Okay, and the final one that I wanted to highlight is in the education record where people are  compressing two degrees into one entry.  It's very challenging to work with because you need to decide whether you're going to  try and split that out or you're going to try and split it, reconcile two degrees and  import it or just quite a few different ways that you could handle this.  Usually it just ends up being things that don't get imported at the moment because there's  a lot more low hanging fruit to take, so why work on the difficult stuff when there's easier  things, it's been my thinking.  But at some point we are going to need to tackle this if we want to import this data.  So I'm suggesting a few next steps of where we might go with this.  Again, this is really to try and start a conversation.  I'm not saying we have to do it this way.  If you disagree, the best thing to do is say so because that will contribute to the conversation  and we can reach some sort of consensus.  I think we really need to consider what is the minimal acceptable standard for author  item data.  I really question whether some of the imports that are happening on mass at the moment are  creating data that's good enough quality and whether with small improvements we could make  quite a big improvement to data quality.  Sorry, that small improvements to the import methodology could make quite big improvements  to the data quality.  I think to help decide whether the standard is good enough, we need to define requirements  for different use cases.  What are we actually doing with author items?  Are we just creating them because we can?  Are we creating them just as a node to link different publications?  Or do we want to do other things with them as well?  When we know that we can start looking at what data is needed for those different use cases.  Some of the other things are just relating to persistent identifiers.  I won't go into those in detail.  I'm currently going through a process of validating my own data imports and trying to identify  problems.  It's very difficult to do that because I haven't stored in the references to put code from  orchids so we have to import the entire set of employment or education summaries rather  than being able to link directly to a specific summary.  Which leads to, I think there's a need to start storing the put codes in references  in wiki data when we're importing data from orchids so we can validate it in the future,  check for updates, etc.  What I really want to do, kind of my motivation behind organizing this whole session, is to  work towards setting up an online workshop so we can actually have discussions and we  can work out how to collaborate around author items.  I know there are other people who are working on improving data quality but we're all quite  disjointed so it would be really good to get interested people together and have a conversation,  think about how we can work collaboratively for the overall good of improving data quality.  So that's a summary of what I'm thinking and what I've been working on so I'm happy to  take any questions or very interested in other people's comments on this topic as well.  Brilliant, thank you very much for that.  Simon, that was really interesting and yes we do have a few minutes for questions.  There are some in the etherpad already but if you have any others and you want to ask  them just pop those in as soon as possible and I'll try and ask Simon.  So the first question we've got for Simon is, is it possible to do a mix and match between  orchids and viath?  Well, mix and match is a tool for importing data to wiki data so not directly I don't  think, you'd have to import data about one to wiki data and then import the other based  on wiki data so probably yes.  I guess wiki data is kind of a mix and match in a way isn't it?  Yeah, it is but not as easy as it's made to sound like.  Cool, there's a comment question.  Someone's a bit worried that wiki data items with orchid IDs might be linked to the wrong  people or incorrectly listed as an author on an item about an article for example.  So do you come across these kind of errors?  What are your thoughts on this?  Yeah, I mean I highlighted one in that presentation which was a glaring error where it was clearly  an organisation that had been created and that was, I believe that happened because  the wrong author in a list of authors on a publication was scraped and imported and associated  with the orchid ID.  So yes, it does happen.  I think there's a serious need for doing data validation across all the scholarly articles  and these mass data imports that haven't been touched by human editors because yes, there  will be errors, it's inevitable but I have no idea how big a problem that would be.  Okay, thank you.  The question is, do you have any thoughts on using DBLP as a preferred identifier with  a fallback to orchid?  That makes sense?  Yeah, it does make sense.  I don't know why you'd use it as a preferred identifier.  I'll use it as an extra identifier on top of orchid and probably fall back to DBLP rather  than give way round.  That's a personal preference I suppose.  Just to elaborate on that slightly, I would say because orchid is curated by the author,  it's an unusually reliable source although obviously times when that could be a problem  but in general it's probably the best source of data we have for author items and then  afterwards we should start looking at other sources where orchid isn't helpful.  Fantastic.  I think that's about it for questions.  Apologies if you have posted a question somewhere and we haven't seen it but I'm sure Simon will  be happy to take questions on Telegram or anywhere else during the afternoon.  Yeah, very much so.  We've got a break later on so if any questions emerge you can potentially take them later  or just general questions that can come up during the afternoon or if you have a question  you think of it later just send me a message on Wicked Data.  I'm on there all the time so we'll know you'll be fine quite quickly.
Wikicite_2020__Author_Items_Vid_2_0_83.png Wikicite_2020__Author_Items_Vid_2_84_383.png Wikicite_2020__Author_Items_Vid_2_384_875.png Wikicite_2020__Author_Items_Vid_2_876_2351.png Wikicite_2020__Author_Items_Vid_2_2352_2435.png Wikicite_2020__Author_Items_Vid_2_2436_2519.png Wikicite_2020__Author_Items_Vid_2_2520_2567.png Wikicite_2020__Author_Items_Vid_2_2568_2615.png Wikicite_2020__Author_Items_Vid_2_2616_2711.png Wikicite_2020__Author_Items_Vid_2_2712_2759.png Wikicite_2020__Author_Items_Vid_2_2760_2867.png Wikicite_2020__Author_Items_Vid_2_2868_2999.png Wikicite_2020__Author_Items_Vid_2_3000_3695.png Wikicite_2020__Author_Items_Vid_2_3696_3743.png Wikicite_2020__Author_Items_Vid_2_3744_3791.png Wikicite_2020__Author_Items_Vid_2_3792_3863.png Wikicite_2020__Author_Items_Vid_2_3864_3911.png Wikicite_2020__Author_Items_Vid_2_3912_3959.png Wikicite_2020__Author_Items_Vid_2_3960_5195.png Wikicite_2020__Author_Items_Vid_2_5196_10259.png Wikicite_2020__Author_Items_Vid_2_10260_10715.png Wikicite_2020__Author_Items_Vid_2_10716_13079.png Wikicite_2020__Author_Items_Vid_2_13080_14879.png Wikicite_2020__Author_Items_Vid_2_14880_18083.png Wikicite_2020__Author_Items_Vid_2_18084_21911.png Wikicite_2020__Author_Items_Vid_2_21912_23639.png Wikicite_2020__Author_Items_Vid_2_23640_27539.png Wikicite_2020__Author_Items_Vid_2_27540_27791.png Wikicite_2020__Author_Items_Vid_2_27792_28367.png Wikicite_2020__Author_Items_Vid_2_28368_29051.png Wikicite_2020__Author_Items_Vid_2_29052_30035.png Wikicite_2020__Author_Items_Vid_2_30036_31283.png Wikicite_2020__Author_Items_Vid_2_31284_35519.png Wikicite_2020__Author_Items_Vid_2_35520_35807.png Wikicite_2020__Author_Items_Vid_2_35808_37643.png Wikicite_2020__Author_Items_Vid_2_37644_38027.png Wikicite_2020__Author_Items_Vid_2_38028_38675.png Wikicite_2020__Author_Items_Vid_2_38676_38951.png Wikicite_2020__Author_Items_Vid_2_38952_41651.png Wikicite_2020__Author_Items_Vid_2_41652_41682.png