A RESTful JSON-LD Architecture for Unraveling Hidden References to Research Data
Baierer, Konstantin
Zumstein, Philipp
Data citations are more common today, but more often than not the references to research data don't follow any formalism as do references to publications. The InFoLiS project makes those "hidden" references explicit using text mining techniques. They are made available for integration by software agents (e.g. for retrieval systems). In the second phase of the project we aim to build a flexible and long-term sustainable infrastructure to house the algorithms as well as APIs for embedding them into existing systems. The infrastructure's primary directive is to provide lightweight read/write access to the resources that define the InFoLiS data model (algorithms, metadata, patterns, publications, etc.). The InFoLiS data model is implemented as a JSON schema and provides full forward compatibility with RDF through JSON-LD using a JSON-to-RDF schema-ontology mapping, reusing established vocabularies whenever possible. We are neither using a triplestore nor an RDBMS, but a document database (MongoDB). This allows us to adhere to the Linked Data principles, while minimizing the complexity of mappings between different resource representations. Consequently, our web services are lightweight, making it easy to integrate InFoLiS data into information retrieval systems, publication management systems or reference management software. On the other hand, Linked Data agents expecting RDF can consume the API responses as triples; they can query the SPARQL endpoint or download a full RDF dump of the database. We will demonstrate a lightweight tool that uses the InFoLiS web services to augment the web browsing experience for data scientists and librarians.
 Thank you. And good afternoon, everybody. So just for the first slide overview, so we have kind of four parts, kind of the first two general parts, more a little bit, and then there will be a technical architecture part, and in the final end demonstration about what we can do at the moment and how we can use our tools and stuff like that. So we will talk about the Infolist project, and this is a joint project with the Geysers Geysers Lightnecks Institute for the Social Sciences, and with the University of Mannheim or respectively the Hochschule, the Median Stuttgart, that's one, and we as the Mannheim University Library in Mannheim. It's funded by the DFG, the German Research Foundation, and we are now in the second funding phase. So just that we are on the same level maybe, let's start with some easy stuff, research data. Well, that's just some raw data, imagine some numbers, you have measures, you have made some experiments and you're measuring that, and that will be kind of maybe an intermediate step in your research process, and you're then heading for the publication where you do some nice analysis. So this will be the first possibility, but you can also kind of take research data from a data provider, or from some official statistics, like for countries there are a lot of data available, or also for other organizations or stuff like that, or you can just take the research data from your colleague, given that he or she shares it with you, or maybe has even published it. So if you're using some other work, other scholarly works, well then you have to cite it, and the citation is just some formal structured reference to another scholarly work, data citation is then kind of the thing if the scholarly work is research data. So let's start maybe when does this data citation actually start it. I have here a timeline, I think we have seen at least some of the dates, or more or less already, and the first question I would like to ask, when was the first structured data citation used in a publication? So I claim maybe around the year 2000. If you have any proof or more hints, just send it to us, we are interested kind of to find out maybe a more accurate date. Next question, well when was the first unstructured reference to research data used in a publication? And here we say well that's 1609 or before, and the proof just follows, here is one of the first unstructured data citations. It's a paper or a book actually by Kepler, so he's the author, and the title well actually the whole stuff here above that's the title. If you translate it into English it says, new astronomy based open causes or celestial physics treated by means of commentaries on the motions of the star Mars from the observations of Tichobrai. So we see here he mentions this observation, this research data from Tichobrai, so he cites that, he does some data citation kind of. How does he do that? Well just by, well a little bit above should it be from the observation of Tichobrai, so that's just the sentences here part of the title which is the suggestion that he's, or the data citation kind of. Well that was a long time ago and actually now we have some data citations principles. So these are the eight data citation principles. First one is well it's just important, it's actually as important as other citations, so you should do kind of the same thing as you're doing for the other citations. And you should make it easy or facilitates to give credit and attribution to the authors or to the contributors of this research data. You should evidence, so you should do data citations whenever you're using some research data, you should cite them also as a citation. A unique identification, some global identifier for example, access, how can you access the research data persistence and two more. Currently there are 100, actually exactly 100 institutional supporters. This means if your institution want to become the 101st you have maybe to hurry up a little bit. There are some data centers, publishers and societies, also some library societies are around among them and some others supporters. Well that was the principle kind of, how's kind of in the practice, how does a data citation look? Well here is one format suggested by data side. It's just kind of in format you can use. You start with the creator, then the publication here in parentheses is column, title, point, version, point, publisher, point, resource, type, point, identify. So not so things fancy in there. There's an example. You can maybe move around a little bit and another order, publication here maybe in the end or some other rules about the separation stuff like that. So that's normal thing what citation styles actually are forcing you to do. And actually there are also some other well-known citation styles like API who already has a data citation guidelines included. Some other examples I have here also from the NLM or the Chicago manual have at least four databases they are talking about. And journal, some journal styles as well are listed here. But actually in practice the people they are still doing the same thing as 400 years ago. Namely they are citing or references the research data in the text just by mentioning some words. So for example the first one is the caption of a table and somewhere there's a reference to the research data. Second one is well it just mentioned the IGLU study. And if you read a little bit around you see there should be some connection to reading literacy. Maybe not the first thing when you see you come to mind if you see IGLU. And the third example also it can be scattered around in the text as here where the years are not in the same place and some other words in between maybe. So how do you process this? How you can find now the research data? What would be the steps you need? Well there are different steps you have to perform now. Actually the first one we have just done namely the detection of data citation in the running full text. Second one is well you have to resolve and normalize kind of the data citations. So for example the IGLU that stands for the German Internationale Grundschule Lesseuntersuche. And this SERP that's kind of the abbreviation for the socio-economic panel or also in German the socio-economic panel and you can even write that differently. So there are different possibilities or variants here. Next thing is the unique identify the data citations. Actually there was an IGLU study in 2001. There was another one in 2006 and there was one in 2011. Which one was referenced in the paper before? And last step kind of find actually now really decided research data. So you actually you're after some URL or maybe then just the location. And while the steps they are kind of annoying you don't want to spend a lot of time and actually you don't maybe not no time at all just see it maybe even in the beginning that would be nice. So the question is here is it possible that we can some of these steps automate maybe some tools some algorithm work can help us here. And that's exactly the goal or one of the goal for the Infolace project. Automating these processing steps. So this means automatically unraveling hidden references in the running text to research data into structured data citations with URIs. And this all should happen in a flexible long term substantial infrastructure. So here's an overall view about the project. So as always we need some data like the full text metadata stuff like that from research data from publications and then our algorithms they can work on that. They are relying on or there are some data mining algorithms and they are using some bootstrapping strategies and some other stuff like there. We will not call we will not speak much more about the algorithms but focus on the technical architecture where they are actually in and the technical architecture relies on linked open data and will provide some restful APIs. In between there is some abstract modeling stuff some structure semantics which kind of connects also these algorithms and technical architecture. And you can get out things out of it. There is an integration. We are trying to integrate it in as much as possible and maybe we see that here better. So as the end user well you can for example search in a discovery system. Then you are receiving some publication according to your research and then it would be nice to see on what data where this publication relying on. Or if you go the other way if you are searching in a data repository finding some research data it would actually be nice to see which publication were built on top of this research data. So we need some links linking stuff in between them. However the users they are not only searching in discovery systems and data repository but they are also searching in other stuff which I should mention in a minute. First there is also a question here how actually to best incorporate data connections into library catalogs. That question comes from Horizon report 2014 library edition. Do you search or users search also somewhere else namely for example in Google scholar or they can maybe search on the channel website or wherever actually somewhere in the web they can make a search. And so actually it is also a good question to ask here where and how is the integration of data citation for our users most useful. And we see here actually there is a lot of stuff of different systems we would like to cover in this integration and therefore we need a really flexible infrastructure which allows us to do that. And that's the next what we want to show you. All right so we've just seen that there are various agents involved or possibly involved with the results of our project and this is like a 10,000 feet view of our architecture. We have an internal API which does all the heavy lifting does all the text extraction and so on. That's written in Java and it should be mostly self-contained service. On the other hand we have our public API that should be as flexible as possible should support as many different serializations and data formats as possible and allow a data model to be as complex as needed but still be really fast. So speed is of the essence for us. And that's why we laid down some principles when we started designing this whole architecture. The main thing should be that the API usability is more important than the expressivity of all parts of the model. So we want to support it at the right places but in general the API should be easy to maintain, easy to consume for possible developers and it should be possible to understand the data model. So we tried to postpone the making the data model extremely complicated part to later and start with something simple. Of course it should be restful-ish so not all the aspects of restful architecture are followed closely or orthodoxly but still it's protocol independent so we can reproduce everything on a local client without HTTP. That's really important because it has to be fast as we said. And we decided to use a JSON store versus a triple store because it's really fast. It has native order lists or arrays which everyone who has developed RDF software knows is a real pain with RDF and it has a deterministic structure again which RDF has not. And that makes it easy to use it for closed world validation which is really important for us. So in general we started out with keeping it simple and that's also understandable if we look at the main operations in for this at the moment. There's this bootstrapping part where we try to learn from a simple seed word new patterns to find data type references as Philip showed before and there's multiple levels of recursion involved and it's an iterative process and it's really tough on CPU and on RAM so here speed is much more important than expressivity. As for text extraction so extracting text from PDF which we do a lot and for applying patterns that we found using this bootstrapping process to text files again these must be really fast and there shouldn't be any time lost with serialization or description or complicated data structure problems. Now for the data set resolution that's the part about if we have some string like SOEP what does that refer to which databases must we search how do we rank these results how can we automate the intuition that people put into resolving these data set resolutions and here the expressivity is much more important than speed because we want perfect results. So I still think that deep modeling has its merit and it's important for us. For example data set granularity so if someone refers to SOEP does he mean the whole panel the whole survey every year or just a single year or that's one aspect then there are data set references which cannot be automatically resolved without context like if people write as the results of our study shows and we know we have to know who are those people and what's the context where did we get this from or something like page 15 of the DERP panel which we don't know what it is because we can't find it anywhere but we still want to state that we found somewhere that someone references something that's called the DERP panel. Also for doing like bibliometric analysis or graphing the relationships of the entities in our data store we also want to have the possibility to model this deeply and also for mining the provenance of the things in our data store it would be really helpful to understand it as a set of statements instead of documents. So the question is how do we get the best of both these world of deep modeling and of keeping it simple. And to show you that I'll just briefly explain our architecture. So we have an HTTP server which handles the API calls which has an RDF JSON-LD content negotiating middleware and we have a MongoDB storage because that's really easy to set up and easy to deploy and fast. We are using the Mongoose document mapper to make it a bit easier to work in code. And then we have a mapping tool that will map between the Mongoose schema and the incoming data. So for once this handles RDF requests, it handles requests for our schema but it also handles the restful API requests and exposes our data model in different serializations. And that's all controlled by something we call the TISN and if you are asking yourself what this spidery thing in the middle is with the arrows to everything else, I will explain that now. So TISN is our self-developed format, it's based on, it's just JSON-LD with a bit of a different syntax more oriented towards turtle because that's easier to read and easier to write. And in this we keep all the different aspects. We keep the descriptive part, we keep the database schema part and also the presentation part. So these are the parts that describe the RDF semantics of our data model. We have a class execution with two properties, lock and algorithm which are described in the context. So it's, we happily stole that from JSON-LD. Then we have the database schema part. So there's a collection execution and a property algorithm and they are, the algorithm might maybe required or should be indexed and so on. And lastly this is just an example, this one shouldn't be displayed in the API front end. So yeah, we're mixing different levels but we keep them all in one place which makes it really easy to adapt and to fix things. So one schema to rule them all, that's our general idea. From this one file we generate our ontology, we generate our REST API endpoints and the documentation for them. We generate our database schema and the indexes that make this database fast and a data model explorer which allows us to get a better understanding of how this works. And now let's hope that it works. The joy of live demos. All right, so what we see here are the aspects of our data model. I won't dive into that much detail. Just want to say that execution is the most important thing because we're doing heavily algorithmic stuff here but we also have links between entities for example and patterns. And if I open one of these I see that the context aspect is always the RDF part and I can just open all the RDF descriptions. So here that's, now we're on the RDF level but we could also check out the database level and to see for example to find out why some query is really slow, maybe some field isn't indexed and we can always jump into the real RDF description of some class. For example here, search query described as turtle in this case could also be, I find it always helpful to look at it in JSON-LD because that's really terse or anything else or I could even go crazy and look at some visualization. Right, so that's the data model part. Let's look at what we can do with that. So I just showed that in the demo work, that's nice. So I jump right into it. We have our API exposed using the swagger interface so all the things rest at the something, everything are generated from that file. We can do all the HTTP verbs that are relevant for rest, get, post and so on. But what I want to show you is our simplified API calls to execute something. What I want to execute is a short version of that learning algorithm. I just copy it and paste it. So just really quickly what I'm doing here is I'm executing this frequency-based bootstrapping algorithm for all the files that were tagged with this particular tag. And I start with the seed Albus. So I know that Albus is a dataset reference and I want to find out what can be used from justice information and a lot of files. So let's try it out. Okay, the thing is posted and I get a response also in the location header. And now it has started an execution that's running asynchronously on the server. I open that up and I get, again, the triple view. So I could look at this but we have a bit of a nicer interface. So we see the algorithm is at 50%. Just have to hit F5 a few times. Why did runs? I can just show you these are all the knobs and turns that you can configure for an algorithm. And let's see if you finished. Yes, you finished. Right. So here's generated a lot of patterns. All these patterns are, of course, the referenceable resources generated a lot of text to references. So these are the things like it's open one. And maybe in turtle. These are the extracted elements of the text. So words left of the thing we found and so on. And the pattern, let's check out the pattern as well, which are just fancy, just a fancy word for regular expression. And everything can be tagged and that's how we organize our stuff because that proved to be really fast and simple. And now that we've learned something, let's apply this to a PDF file. So for that, we've written a small JavaScript library, which is really thin. Just does what I just showed you. And I will choose a file. Choose two files. And we'll try to analyze them. And what happens now is he uploads those files to our store. He extracts the text from the PDF files. And now he tries to apply patterns or patterns with a certain tag that I just created to those text files. And yeah, there's a kind of funny bug where it just jumps around. But let's watch it in the, again, the triple view and jump into the monitor view where it does the same thing. But he has already found a lot of patterns. And he has found some links. So let's open one of those. We see this as a link. Again, these links are irreferensible. And the entities from which they link and to which they link, in this case, from a publication into a data set, are irreferensible as well. It's just a little thing that they are not turned into links in this interface, but still it should be irreferensible. Okay. And we see that he has found a reference from this publication that's referenced by this entity to something that's called Anomii Albus. Don't really know, but that's the DOI of the thing. So we've gone the full way. And yeah. So that's it. If you have any questions, feel free to ask them. Get in touch with us. If you have any data that you want to run through this and try it out, it's kind of not that stable or rapid development, depending on how you look at it. Thank you very much.
 Thank you.  And good afternoon, everybody.  So just for the first slide overview, so we have kind of four parts, kind of the first  two general parts, more a little bit, and then there will be a technical architecture  part, and in the final end demonstration about what we can do at the moment and how we can  use our tools and stuff like that.  So we will talk about the Infolist project, and this is a joint project with the Geysers  Geysers Lightnecks Institute for the Social Sciences, and with the University of Mannheim  or respectively the Hochschule, the Median Stuttgart, that's one, and we as the Mannheim  University Library in Mannheim.  It's funded by the DFG, the German Research Foundation, and we are now in the second funding  phase.  So just that we are on the same level maybe, let's start with some easy stuff, research  data.  Well, that's just some raw data, imagine some numbers, you have measures, you have  made some experiments and you're measuring that, and that will be kind of maybe an intermediate  step in your research process, and you're then heading for the publication where you  do some nice analysis.  So this will be the first possibility, but you can also kind of take research data from  a data provider, or from some official statistics, like for countries there are a lot of data  available, or also for other organizations or stuff like that, or you can just take the  research data from your colleague, given that he or she shares it with you, or maybe has  even published it.  So if you're using some other work, other scholarly works, well then you have to cite  it, and the citation is just some formal structured reference to another scholarly work, data  citation is then kind of the thing if the scholarly work is research data.  So let's start maybe when does this data citation actually start it.  I have here a timeline, I think we have seen at least some of the dates, or more or less  already, and the first question I would like to ask, when was the first structured data  citation used in a publication?  So I claim maybe around the year 2000.  If you have any proof or more hints, just send it to us, we are interested kind of to  find out maybe a more accurate date.  Next question, well when was the first unstructured reference to research data used in a publication?  And here we say well that's 1609 or before, and the proof just follows, here is one of  the first unstructured data citations.  It's a paper or a book actually by Kepler, so he's the author, and the title well actually  the whole stuff here above that's the title.  If you translate it into English it says, new astronomy based open causes or celestial  physics treated by means of commentaries on the motions of the star Mars from the observations  of Tichobrai.  So we see here he mentions this observation, this research data from Tichobrai, so he cites  that, he does some data citation kind of.  How does he do that?  Well just by, well a little bit above should it be from the observation of Tichobrai, so  that's just the sentences here part of the title which is the suggestion that he's, or  the data citation kind of.  Well that was a long time ago and actually now we have some data citations principles.  So these are the eight data citation principles.  First one is well it's just important, it's actually as important as other citations,  so you should do kind of the same thing as you're doing for the other citations.  And you should make it easy or facilitates to give credit and attribution to the authors  or to the contributors of this research data.  You should evidence, so you should do data citations whenever you're using some research  data, you should cite them also as a citation.  A unique identification, some global identifier for example, access, how can you access the  research data persistence and two more.  Currently there are 100, actually exactly 100 institutional supporters.  This means if your institution want to become the 101st you have maybe to hurry up a little  bit.  There are some data centers, publishers and societies, also some library societies are  around among them and some others supporters.  Well that was the principle kind of, how's kind of in the practice, how does a data citation  look?  Well here is one format suggested by data side.  It's just kind of in format you can use.  You start with the creator, then the publication here in parentheses is column, title, point,  version, point, publisher, point, resource, type, point, identify.  So not so things fancy in there.  There's an example.  You can maybe move around a little bit and another order, publication here maybe in the  end or some other rules about the separation stuff like that.  So that's normal thing what citation styles actually are forcing you to do.  And actually there are also some other well-known citation styles like API who already has a  data citation guidelines included.  Some other examples I have here also from the NLM or the Chicago manual have at least  four databases they are talking about.  And journal, some journal styles as well are listed here.  But actually in practice the people they are still doing the same thing as 400 years ago.  Namely they are citing or references the research data in the text just by mentioning some words.  So for example the first one is the caption of a table and somewhere there's a reference  to the research data.  Second one is well it just mentioned the IGLU study.  And if you read a little bit around you see there should be some connection to reading  literacy.  Maybe not the first thing when you see you come to mind if you see IGLU.  And the third example also it can be scattered around in the text as here where the years  are not in the same place and some other words in between maybe.  So how do you process this?  How you can find now the research data?  What would be the steps you need?  Well there are different steps you have to perform now.  Actually the first one we have just done namely the detection of data citation in the running  full text.  Second one is well you have to resolve and normalize kind of the data citations.  So for example the IGLU that stands for the German Internationale Grundschule Lesseuntersuche.  And this SERP that's kind of the abbreviation for the socio-economic panel or also in German  the socio-economic panel and you can even write that differently.  So there are different possibilities or variants here.  Next thing is the unique identify the data citations.  Actually there was an IGLU study in 2001.  There was another one in 2006 and there was one in 2011.  Which one was referenced in the paper before?  And last step kind of find actually now really decided research data.  So you actually you're after some URL or maybe then just the location.  And while the steps they are kind of annoying you don't want to spend a lot of time and  actually you don't maybe not no time at all just see it maybe even in the beginning that  would be nice.  So the question is here is it possible that we can some of these steps automate maybe some  tools some algorithm work can help us here.  And that's exactly the goal or one of the goal for the Infolace project.  Automating these processing steps.  So this means automatically unraveling hidden references in the running text to research  data into structured data citations with URIs.  And this all should happen in a flexible long term substantial infrastructure.  So here's an overall view about the project.  So as always we need some data like the full text metadata stuff like that from research  data from publications and then our algorithms they can work on that.  They are relying on or there are some data mining algorithms and they are using some  bootstrapping strategies and some other stuff like there.  We will not call we will not speak much more about the algorithms but focus on the technical  architecture where they are actually in and the technical architecture relies on linked  open data and will provide some restful APIs.  In between there is some abstract modeling stuff some structure semantics which kind  of connects also these algorithms and technical architecture.  And you can get out things out of it.  There is an integration.  We are trying to integrate it in as much as possible and maybe we see that here better.  So as the end user well you can for example search in a discovery system.  Then you are receiving some publication according to your research and then it would be nice  to see on what data where this publication relying on.  Or if you go the other way if you are searching in a data repository finding some research  data it would actually be nice to see which publication were built on top of this research  data.  So we need some links linking stuff in between them.  However the users they are not only searching in discovery systems and data repository but  they are also searching in other stuff which I should mention in a minute.  First there is also a question here how actually to best incorporate data connections into library  catalogs.  That question comes from Horizon report 2014 library edition.  Do you search or users search also somewhere else namely for example in Google scholar  or they can maybe search on the channel website or wherever actually somewhere in the web  they can make a search.  And so actually it is also a good question to ask here where and how is the integration  of data citation for our users most useful.  And we see here actually there is a lot of stuff of different systems we would like to  cover in this integration and therefore we need a really flexible infrastructure which  allows us to do that.  And that's the next what we want to show you.  All right so we've just seen that there are various agents involved or possibly involved  with the results of our project and this is like a 10,000 feet view of our architecture.  We have an internal API which does all the heavy lifting does all the text extraction  and so on.  That's written in Java and it should be mostly self-contained service.  On the other hand we have our public API that should be as flexible as possible should  support as many different serializations and data formats as possible and allow a data model  to be as complex as needed but still be really fast.  So speed is of the essence for us.  And that's why we laid down some principles when we started designing this whole architecture.  The main thing should be that the API usability is more important than the expressivity of  all parts of the model.  So we want to support it at the right places but in general the API should be easy to maintain,  easy to consume for possible developers and it should be possible to understand the data  model.  So we tried to postpone the making the data model extremely complicated part to later  and start with something simple.  Of course it should be restful-ish so not all the aspects of restful architecture are  followed closely or orthodoxly but still it's protocol independent so we can reproduce everything  on a local client without HTTP.  That's really important because it has to be fast as we said.  And we decided to use a JSON store versus a triple store because it's really fast.  It has native order lists or arrays which everyone who has developed RDF software knows is a  real pain with RDF and it has a deterministic structure again which RDF has not.  And that makes it easy to use it for closed world validation which is really important  for us.  So in general we started out with keeping it simple and that's also understandable if  we look at the main operations in for this at the moment.  There's this bootstrapping part where we try to learn from a simple seed word new patterns  to find data type references as Philip showed before and there's multiple levels of recursion  involved and it's an iterative process and it's really tough on CPU and on RAM so here  speed is much more important than expressivity.  As for text extraction so extracting text from PDF which we do a lot and for applying patterns  that we found using this bootstrapping process to text files again these must be really fast  and there shouldn't be any time lost with serialization or description or complicated  data structure problems.  Now for the data set resolution that's the part about if we have some string like SOEP  what does that refer to which databases must we search how do we rank these results how  can we automate the intuition that people put into resolving these data set resolutions  and here the expressivity is much more important than speed because we want perfect results.  So I still think that deep modeling has its merit and it's important for us.  For example data set granularity so if someone refers to SOEP does he mean the whole panel  the whole survey every year or just a single year or that's one aspect then there are data  set references which cannot be automatically resolved without context like if people write  as the results of our study shows and we know we have to know who are those people and what's  the context where did we get this from or something like page 15 of the DERP panel which  we don't know what it is because we can't find it anywhere but we still want to state  that we found somewhere that someone references something that's called the DERP panel.  Also for doing like bibliometric analysis or graphing the relationships of the entities  in our data store we also want to have the possibility to model this deeply and also  for mining the provenance of the things in our data store it would be really helpful  to understand it as a set of statements instead of documents.  So the question is how do we get the best of both these world of deep modeling and of  keeping it simple.  And to show you that I'll just briefly explain our architecture.  So we have an HTTP server which handles the API calls which has an RDF JSON-LD content  negotiating middleware and we have a MongoDB storage because that's really easy to set  up and easy to deploy and fast.  We are using the Mongoose document mapper to make it a bit easier to work in code.  And then we have a mapping tool that will map between the Mongoose schema and the incoming  data.  So for once this handles RDF requests, it handles requests for our schema but it also  handles the restful API requests and exposes our data model in different serializations.  And that's all controlled by something we call the TISN and if you are asking yourself  what this spidery thing in the middle is with the arrows to everything else, I will explain  that now.  So TISN is our self-developed format, it's based on, it's just JSON-LD with a bit of  a different syntax more oriented towards turtle because that's easier to read and easier to  write.  And in this we keep all the different aspects.  We keep the descriptive part, we keep the database schema part and also the presentation  part.  So these are the parts that describe the RDF semantics of our data model.  We have a class execution with two properties, lock and algorithm which are described in  the context.  So it's, we happily stole that from JSON-LD.  Then we have the database schema part.  So there's a collection execution and a property algorithm and they are, the algorithm might  maybe required or should be indexed and so on.  And lastly this is just an example, this one shouldn't be displayed in the API front end.  So yeah, we're mixing different levels but we keep them all in one place which makes  it really easy to adapt and to fix things.  So one schema to rule them all, that's our general idea.  From this one file we generate our ontology, we generate our REST API endpoints and the  documentation for them.  We generate our database schema and the indexes that make this database fast and a data model  explorer which allows us to get a better understanding of how this works.  And now let's hope that it works.  The joy of live demos.  All right, so what we see here are the aspects of our data model.  I won't dive into that much detail.  Just want to say that execution is the most important thing because we're doing heavily  algorithmic stuff here but we also have links between entities for example and patterns.  And if I open one of these I see that the context aspect is always the RDF part and  I can just open all the RDF descriptions.  So here that's, now we're on the RDF level but we could also check out the database level  and to see for example to find out why some query is really slow, maybe some field isn't  indexed and we can always jump into the real RDF description of some class.  For example here, search query described as turtle in this case could also be, I find  it always helpful to look at it in JSON-LD because that's really terse or anything else  or I could even go crazy and look at some visualization.  Right, so that's the data model part.  Let's look at what we can do with that.  So I just showed that in the demo work, that's nice.  So I jump right into it.  We have our API exposed using the swagger interface so all the things rest at the something,  everything are generated from that file.  We can do all the HTTP verbs that are relevant for rest, get, post and so on.  But what I want to show you is our simplified API calls to execute something.  What I want to execute is a short version of that learning algorithm.  I just copy it and paste it.  So just really quickly what I'm doing here is I'm executing this frequency-based bootstrapping  algorithm for all the files that were tagged with this particular tag.  And I start with the seed Albus.  So I know that Albus is a dataset reference and I want to find out what can be used from  justice information and a lot of files.  So let's try it out.  Okay, the thing is posted and I get a response also in the location header.  And now it has started an execution that's running asynchronously on the server.  I open that up and I get, again, the triple view.  So I could look at this but we have a bit of a nicer interface.  So we see the algorithm is at 50%.  Just have to hit F5 a few times.  Why did runs?  I can just show you these are all the knobs and turns that you can configure for an algorithm.  And let's see if you finished.  Yes, you finished.  Right.  So here's generated a lot of patterns.  All these patterns are, of course, the referenceable resources generated a lot of text to references.  So these are the things like it's open one.  And maybe in turtle.  These are the extracted elements of the text.  So words left of the thing we found and so on.  And the pattern, let's check out the pattern as well, which are just fancy, just a fancy  word for regular expression.  And everything can be tagged and that's how we organize our stuff because that proved  to be really fast and simple.  And now that we've learned something, let's apply this to a PDF file.  So for that, we've written a small JavaScript library, which is really thin.  Just does what I just showed you.  And I will choose a file.  Choose two files.  And we'll try to analyze them.  And what happens now is he uploads those files to our store.  He extracts the text from the PDF files.  And now he tries to apply patterns or patterns with a certain tag that I just created to  those text files.  And yeah, there's a kind of funny bug where it just jumps around.  But let's watch it in the, again, the triple view and jump into the monitor view where  it does the same thing.  But he has already found a lot of patterns.  And he has found some links.  So let's open one of those.  We see this as a link.  Again, these links are irreferensible.  And the entities from which they link and to which they link, in this case, from a publication  into a data set, are irreferensible as well.  It's just a little thing that they are not turned into links in this interface, but still  it should be irreferensible.  Okay.  And we see that he has found a reference from this publication that's referenced by this  entity to something that's called Anomii Albus.  Don't really know, but that's the DOI of the thing.  So we've gone the full way.  And yeah.  So that's it.  If you have any questions, feel free to ask them.  Get in touch with us.  If you have any data that you want to run through this and try it out, it's kind of not that  stable or rapid development, depending on how you look at it.  Thank you very much.
A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_0_5999.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_6000_7775.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_7776_10787.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_10788_17927.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_17928_26183.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_26184_30395.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_30396_31667.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_31668_32195.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_32196_32975.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_32976_33335.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_33336_33539.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_33540_33911.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_33912_34427.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_34428_34499.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_34500_34667.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_34668_34727.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_34728_34811.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_34812_35687.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_35688_35975.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_35976_36167.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_36168_36611.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_36612_36803.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_36804_37187.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_37188_37367.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_37368_37967.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_37968_38171.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_38172_38219.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_38220_38315.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_38316_38819.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_38820_39107.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_39108_39479.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_39480_39587.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_39588_40259.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_40260_40319.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_40320_40367.png A_RESTful_JSON-LD_Architecture_for_Unraveling_Hidd_-Wtd6pouGEw_40368_40384.png
Thank you. And good afternoon, everybody. So just for the first slide overview, so we have kind of four parts, kind of the first two general parts, more a little bit, and then there will be a technical architecture part, and in the final end demonstration about what we can do at the moment and how we can use our tools and stuff like that. So we will talk about the Infolist project, and this is a joint project with the Geysers Geysers Lightnecks Institute for the Social Sciences, and with the University of Mannheim or respectively the Hochschule, the Median Stuttgart, that's one, and we as the Mannheim University Library in Mannheim. It's funded by the DFG, the German Research Foundation, and we are now in the second funding phase. So just that we are on the same level maybe, let's start with some easy stuff, research data. Well, that's just some raw data, imagine some numbers, you have measures, you have made some experiments and you're measuring that, and that will be kind of maybe an intermediate step in your research process, and you're then heading for the publication where you do some nice analysis. So this will be the first possibility, but you can also kind of take research data from a data provider, or from some official statistics, like for countries there are a lot of data available, or also for other organizations or stuff like that, or you can just take the research data from your colleague, given that he or she shares it with you, or maybe has even published it. So if you're using some other work, other scholarly works, well then you have to cite it, and the citation is just some formal structured reference to another scholarly work, data citation is then kind of the thing if the scholarly work is research data. So let's start maybe when does this data citation actually start it. I have here a timeline, I think we have seen at least some of the dates, or more or less already, and the first question I would like to ask, when was the first structured data citation used in a publication? So I claim maybe around the year 2000. If you have any proof or more hints, just send it to us, we are interested kind of to find out maybe a more accurate date. Next question, well when was the first unstructured reference to research data used in a publication? And here we say well that's 1609 or before, and the proof just follows, here is one of the first unstructured data citations. It's a paper or a book actually by Kepler, so he's the author, and the title well actually the whole stuff here above that's the title. If you translate it into English it says, new astronomy based open causes or celestial physics treated by means of commentaries on the motions of the star Mars from the observations of Tichobrai. So we see here he mentions this observation, this research data from Tichobrai, so he cites that, he does some data citation kind of. How does he do that? Well just by, well a little bit above should it be from the observation of Tichobrai, so that's just the sentences here part of the title which is the suggestion that he's, or the data citation kind of. Well that was a long time ago and actually now we have some data citations principles. So these are the eight data citation principles. First one is well it's just important, it's actually as important as other citations, so you should do kind of the same thing as you're doing for the other citations. And you should make it easy or facilitates to give credit and attribution to the authors or to the contributors of this research data. You should evidence, so you should do data citations whenever you're using some research data, you should cite them also as a citation. A unique identification, some global identifier for example, access, how can you access the research data persistence and two more. Currently there are 100, actually exactly 100 institutional supporters. This means if your institution want to become the 101st you have maybe to hurry up a little bit. There are some data centers, publishers and societies, also some library societies are around among them and some others supporters. Well that was the principle kind of, how's kind of in the practice, how does a data citation look? Well here is one format suggested by data side. It's just kind of in format you can use. You start with the creator, then the publication here in parentheses is column, title, point, version, point, publisher, point, resource, type, point, identify. So not so things fancy in there. There's an example. You can maybe move around a little bit and another order, publication here maybe in the end or some other rules about the separation stuff like that. So that's normal thing what citation styles actually are forcing you to do. And actually there are also some other well-known citation styles like API who already has a data citation guidelines included. Some other examples I have here also from the NLM or the Chicago manual have at least four databases they are talking about. And journal, some journal styles as well are listed here. But actually in practice the people they are still doing the same thing as 400 years ago. Namely they are citing or references the research data in the text just by mentioning some words. So for example the first one is the caption of a table and somewhere there's a reference to the research data. Second one is well it just mentioned the IGLU study. And if you read a little bit around you see there should be some connection to reading literacy. Maybe not the first thing when you see you come to mind if you see IGLU. And the third example also it can be scattered around in the text as here where the years are not in the same place and some other words in between maybe. So how do you process this? How you can find now the research data? What would be the steps you need? Well there are different steps you have to perform now. Actually the first one we have just done namely the detection of data citation in the running full text. Second one is well you have to resolve and normalize kind of the data citations. So for example the IGLU that stands for the German Internationale Grundschule Lesseuntersuche. And this SERP that's kind of the abbreviation for the socio-economic panel or also in German the socio-economic panel and you can even write that differently. So there are different possibilities or variants here. Next thing is the unique identify the data citations. Actually there was an IGLU study in 2001. There was another one in 2006 and there was one in 2011. Which one was referenced in the paper before? And last step kind of find actually now really decided research data. So you actually you're after some URL or maybe then just the location. And while the steps they are kind of annoying you don't want to spend a lot of time and actually you don't maybe not no time at all just see it maybe even in the beginning that would be nice. So the question is here is it possible that we can some of these steps automate maybe some tools some algorithm work can help us here. And that's exactly the goal or one of the goal for the Infolace project. Automating these processing steps. So this means automatically unraveling hidden references in the running text to research data into structured data citations with URIs. And this all should happen in a flexible long term substantial infrastructure. So here's an overall view about the project. So as always we need some data like the full text metadata stuff like that from research data from publications and then our algorithms they can work on that. They are relying on or there are some data mining algorithms and they are using some bootstrapping strategies and some other stuff like there. We will not call we will not speak much more about the algorithms but focus on the technical architecture where they are actually in and the technical architecture relies on linked open data and will provide some restful APIs. In between there is some abstract modeling stuff some structure semantics which kind of connects also these algorithms and technical architecture. And you can get out things out of it. There is an integration. We are trying to integrate it in as much as possible and maybe we see that here better. So as the end user well you can for example search in a discovery system. Then you are receiving some publication according to your research and then it would be nice to see on what data where this publication relying on. Or if you go the other way if you are searching in a data repository finding some research data it would actually be nice to see which publication were built on top of this research data. So we need some links linking stuff in between them. However the users they are not only searching in discovery systems and data repository but they are also searching in other stuff which I should mention in a minute. First there is also a question here how actually to best incorporate data connections into library catalogs. That question comes from Horizon report 2014 library edition. Do you search or users search also somewhere else namely for example in Google scholar or they can maybe search on the channel website or wherever actually somewhere in the web they can make a search. And so actually it is also a good question to ask here where and how is the integration of data citation for our users most useful. And we see here actually there is a lot of stuff of different systems we would like to cover in this integration and therefore we need a really flexible infrastructure which allows us to do that. And that's the next what we want to show you. All right so we've just seen that there are various agents involved or possibly involved with the results of our project and this is like a 10,000 feet view of our architecture. We have an internal API which does all the heavy lifting does all the text extraction and so on. That's written in Java and it should be mostly self-contained service. On the other hand we have our public API that should be as flexible as possible should support as many different serializations and data formats as possible and allow a data model to be as complex as needed but still be really fast. So speed is of the essence for us. And that's why we laid down some principles when we started designing this whole architecture. The main thing should be that the API usability is more important than the expressivity of all parts of the model. So we want to support it at the right places but in general the API should be easy to maintain, easy to consume for possible developers and it should be possible to understand the data model. So we tried to postpone the making the data model extremely complicated part to later and start with something simple. Of course it should be restful-ish so not all the aspects of restful architecture are followed closely or orthodoxly but still it's protocol independent so we can reproduce everything on a local client without HTTP. That's really important because it has to be fast as we said. And we decided to use a JSON store versus a triple store because it's really fast. It has native order lists or arrays which everyone who has developed RDF software knows is a real pain with RDF and it has a deterministic structure again which RDF has not. And that makes it easy to use it for closed world validation which is really important for us. So in general we started out with keeping it simple and that's also understandable if we look at the main operations in for this at the moment. There's this bootstrapping part where we try to learn from a simple seed word new patterns to find data type references as Philip showed before and there's multiple levels of recursion involved and it's an iterative process and it's really tough on CPU and on RAM so here speed is much more important than expressivity. As for text extraction so extracting text from PDF which we do a lot and for applying patterns that we found using this bootstrapping process to text files again these must be really fast and there shouldn't be any time lost with serialization or description or complicated data structure problems. Now for the data set resolution that's the part about if we have some string like SOEP what does that refer to which databases must we search how do we rank these results how can we automate the intuition that people put into resolving these data set resolutions and here the expressivity is much more important than speed because we want perfect results. So I still think that deep modeling has its merit and it's important for us. For example data set granularity so if someone refers to SOEP does he mean the whole panel the whole survey every year or just a single year or that's one aspect then there are data set references which cannot be automatically resolved without context like if people write as the results of our study shows and we know we have to know who are those people and what's the context where did we get this from or something like page 15 of the DERP panel which we don't know what it is because we can't find it anywhere but we still want to state that we found somewhere that someone references something that's called the DERP panel. Also for doing like bibliometric analysis or graphing the relationships of the entities in our data store we also want to have the possibility to model this deeply and also for mining the provenance of the things in our data store it would be really helpful to understand it as a set of statements instead of documents. So the question is how do we get the best of both these world of deep modeling and of keeping it simple. And to show you that I'll just briefly explain our architecture. So we have an HTTP server which handles the API calls which has an RDF JSON-LD content negotiating middleware and we have a MongoDB storage because that's really easy to set up and easy to deploy and fast. We are using the Mongoose document mapper to make it a bit easier to work in code. And then we have a mapping tool that will map between the Mongoose schema and the incoming data. So for once this handles RDF requests, it handles requests for our schema but it also handles the restful API requests and exposes our data model in different serializations. And that's all controlled by something we call the TISN and if you are asking yourself what this spidery thing in the middle is with the arrows to everything else, I will explain that now. So TISN is our self-developed format, it's based on, it's just JSON-LD with a bit of a different syntax more oriented towards turtle because that's easier to read and easier to write. And in this we keep all the different aspects. We keep the descriptive part, we keep the database schema part and also the presentation part. So these are the parts that describe the RDF semantics of our data model. We have a class execution with two properties, lock and algorithm which are described in the context. So it's, we happily stole that from JSON-LD. Then we have the database schema part. So there's a collection execution and a property algorithm and they are, the algorithm might maybe required or should be indexed and so on. And lastly this is just an example, this one shouldn't be displayed in the API front end. So yeah, we're mixing different levels but we keep them all in one place which makes it really easy to adapt and to fix things. So one schema to rule them all, that's our general idea. From this one file we generate our ontology, we generate our REST API endpoints and the documentation for them. We generate our database schema and the indexes that make this database fast and a data model explorer which allows us to get a better understanding of how this works. And now let's hope that it works. The joy of live demos. All right, so what we see here are the aspects of our data model. I won't dive into that much detail. Just want to say that execution is the most important thing because we're doing heavily algorithmic stuff here but we also have links between entities for example and patterns. And if I open one of these I see that the context aspect is always the RDF part and I can just open all the RDF descriptions. So here that's, now we're on the RDF level but we could also check out the database level and to see for example to find out why some query is really slow, maybe some field isn't indexed and we can always jump into the real RDF description of some class. For example here, search query described as turtle in this case could also be, I find it always helpful to look at it in JSON-LD because that's really terse or anything else or I could even go crazy and look at some visualization. Right, so that's the data model part. Let's look at what we can do with that. So I just showed that in the demo work, that's nice. So I jump right into it. We have our API exposed using the swagger interface so all the things rest at the something, everything are generated from that file. We can do all the HTTP verbs that are relevant for rest, get, post and so on. But what I want to show you is our simplified API calls to execute something. What I want to execute is a short version of that learning algorithm. I just copy it and paste it. So just really quickly what I'm doing here is I'm executing this frequency-based bootstrapping algorithm for all the files that were tagged with this particular tag. And I start with the seed Albus. So I know that Albus is a dataset reference and I want to find out what can be used from justice information and a lot of files. So let's try it out. Okay, the thing is posted and I get a response also in the location header. And now it has started an execution that's running asynchronously on the server. I open that up and I get, again, the triple view. So I could look at this but we have a bit of a nicer interface. So we see the algorithm is at 50%. Just have to hit F5 a few times. Why did runs? I can just show you these are all the knobs and turns that you can configure for an algorithm. And let's see if you finished. Yes, you finished. Right. So here's generated a lot of patterns. All these patterns are, of course, the referenceable resources generated a lot of text to references. So these are the things like it's open one. And maybe in turtle. These are the extracted elements of the text. So words left of the thing we found and so on. And the pattern, let's check out the pattern as well, which are just fancy, just a fancy word for regular expression. And everything can be tagged and that's how we organize our stuff because that proved to be really fast and simple. And now that we've learned something, let's apply this to a PDF file. So for that, we've written a small JavaScript library, which is really thin. Just does what I just showed you. And I will choose a file. Choose two files. And we'll try to analyze them. And what happens now is he uploads those files to our store. He extracts the text from the PDF files. And now he tries to apply patterns or patterns with a certain tag that I just created to those text files. And yeah, there's a kind of funny bug where it just jumps around. But let's watch it in the, again, the triple view and jump into the monitor view where it does the same thing. But he has already found a lot of patterns. And he has found some links. So let's open one of those. We see this as a link. Again, these links are irreferensible. And the entities from which they link and to which they link, in this case, from a publication into a data set, are irreferensible as well. It's just a little thing that they are not turned into links in this interface, but still it should be irreferensible. Okay. And we see that he has found a reference from this publication that's referenced by this entity to something that's called Anomii Albus. Don't really know, but that's the DOI of the thing. So we've gone the full way. And yeah. So that's it. If you have any questions, feel free to ask them. Get in touch with us. If you have any data that you want to run through this and try it out, it's kind of not that stable or rapid development, depending on how you look at it. Thank you very much.
Research Foundation, and we are now in the second made some experiments and you're measuring that, a lot of data available, or also for other reference to research data used in a publication? now we have some data citations principles. So you should do data citations whenever you're using some research data, you should cite them you access the research data persistence and two And journal, some journal styles as well are research data in the text just by mentioning some a lot of time and actually you don't maybe not no automatically unraveling hidden references in the running text to research data into structured the project. So as always we need some data like the full text metadata stuff like that from research data from publications and then our algorithms they can work on that. They are relying on or there are some data mining the algorithms but focus on the technical and will provide some restful APIs. In between integration. We are trying to integrate it in as website or wherever actually somewhere in the web lot of stuff of different systems we would like need a really flexible infrastructure which allows us to do that. And that's the next what we that there are various agents involved or the other hand we have our public API that should that the API usability is more important than the to consume for possible developers and it should tried to postpone the making the data model handles the API calls which has an RDF JSON-LD to work in code. And then we have a mapping tool exposes our data model in different the database schema part and also the place which makes it really easy to adapt and to are, of course, the referenceable resources with us. If you have any data that you want to