LOD for Applications - Using the Lobid API
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.
Christoph, Pascal
Steeg, Fabian
It is often correctly noted that many datasets got published in the library world with little or no stories about actual use of these datasets. In this talk we want to highlight some of this usage in the context of the hbz linked open data service lobid (which stands for "linking open bibliographic data"). The hbz has been experimenting with linked data technology since 2009. In November 2013 the hbz launched a linked open data API via its service lobid. This API provides access to different kinds of data: • bibliographic data from the hbz union catalogue with 20 million records and 45 million holdings • authority data from the German Integrated Authority File (Gemeinsame Normdatei, GND) with subject headings, persons, corporate bodies, events, places and works • address data on libraries and related institutions, taken from the German ISIL registry and the MARC organization codes data base. The talk starts with a brief outline of the concept and the technology used behind the lobid API and how lobid itself benefits from other linked data sources. After that it is shown how applications are making use of the lobid API, focusing on the development of the North Rhine-Westphalian bibliography (NWBib) as an example. In the end we provide some lessons learned regarding the transformation of legacy data to linked data and the provision of a web API for it. SWIB15 Conference, 23 - 25 November 2015, Hamburg, Germany. #swib15
 Thank you, David. I'm just going to get the resolution right. Okay, so hello everybody. I have recently stumbled upon this poster by the American Library Association from 1925. It advertises library work as the profession on which all other professions and occupations depend. Now, I'm sure that anybody who does library work kind of likes that sentiment, I certainly do. But at the same time, it makes you wonder how true that statement actually is. Even back then, for instance, my grandfather was a baker. I don't think he actually depended on library work. But even more so, it makes you wonder how true that is today. And I don't have an answer on that, but to the extent that this is true today, there is something else involved. That software. Because software is also something in which every profession and occupation depends. Now, as the previous statement wasn't quite true, this also isn't quite true. There are certainly professions which don't depend on software today. But there is one profession which certainly does. And that's library work. Because libraries are software. The services that libraries provide are provided directly or indirectly through software. So this talk is called Lot for Applications using the Lobbit API, which stands for Application Programming Interface. Now, why would we want to use an API? Well, because Lot for Applications means building software. And APIs make software development manageable. They allow us to build modular software with stable applications where changes in parts of the software don't require changes in all the other parts, particularly the applications. At the same time, APIs allow us to have flexible data sources. So let's take a look at what this means for the Lobbit API. So through the Lobbit API, in the Lobbit API, we make available authority data from different sources in different formats, geo data from Wickey data, and title data from our union catalog. And all this data is made available to the applications through this API. So the API really decoupled the applications from these specific data sources, formats, and systems. So these systems, formats, and sources can change without requiring applications to change at the same time. Because the API provides this decoupling. All right, so the subtitle of this talk is Using the Lobbit API. Now, what does that even mean, using an API? So for web APIs, it basically means opening URLs. So it's just like opening a website, but what we want back is structured data. So let's take a look at how we can do this by using the Lobbit API. We basically just open a browser in the URL bar, we specify we want something from our organizations API, and then we search, for instance, for Habit Set, which is the organization I work for. And we get back some structured data. Now, in the address bar, we just change Habit Set, say, to SetBV, and we get different data. So we're using the API. Now, the idea is that the same URL we could use in a different way. For instance, we can call that URL from the command line to get bike downloads, for instance. So we can use Curl, and we can pass a format that we want, for instance, JSON-LD, and we can pass that we want it in a zip form, so we have less disk usage. And then we pass arbitrary queries in the form of a URL. So for instance, we can get all the holdings of a specific library, or we can get all new titles with a specific subject, and then we redirect this into the file. And what we have is local data, which is ready for offline usage, but we still got it from the API. So there is no contradiction between dumps and local data for offline usage and an API. The API is just the means for delivery of that data. All right, so let's take a look at a concrete application. We can answer a single question like, how many libraries are there in Germany? The traditional answer is 10,000, so is it 10,000, or is it more like 20,000, which was an initial result we got when we asked and kind of asked our API this question. So let's take a look at how we can do this by using the Lobbit API. This is a single organization in our API, and we can see that there is a type field, which says that this particular organization is a library, so this is something that we will be using, because we want libraries. And we have an address country field, which is nested within an address within a list of locations, and this address country specifies that this is Germany. So here we see the data, and based on this we can create a query where we say the type should be library, and the location address address country, this nested field, should be Germany. And in the result we get a field which specifies the total number of results, so we have an answer for this question, it's 13,279 libraries in Germany, according to our data and our API. Now as I said before, this initial request, it said about 20,000, so what about that? It's really that using a lot for applications, by using the Lobbit API, we were able to improve the query, so in the initial query we didn't consider the location, because all our organizations in this API are German organizations, but they are not all inside of Germany, like Gritte Institutes. And we were able to improve our data, because if your result is like the double of the common answer, you send it to check what you're doing, and we realized that we were taking into account inactive libraries. So we really see that usage leads to improvement. Alright, so let's take a look at a concrete application. Say we want to visualize data on a map, like the libraries in Hamburg. So let's take a look at how we can do that with the Lobbit API. The starting point again is a query like before, we say the type should be library, and the location address, in this case we say address locality, not the address country, should be Hamburg. Now our question was how many are there in Hamburg, the answer would be up here, 153, but in this case we want to use the data to create this map visualization. In particular we want to use the geo-coordinate down here. So a location has an address, but also a geo-location. So to do that we create an HTML file. In the head of the HTML file we integrate a mapping library, we create a map down here, and then we call the Lobbit API with this very query. We say we want something with type library and location address locality, Hamburg. Then we process the result down here, and finally create a marker on the map using this geo-latitude and geo-longitude from the data. And what we get is this, I try to switch to a live version of this. Connection is too slow. You would see that you can zoom in and out, you can pan around, and you can click on these markers to get the name of the library. This is to complete files for the result that you saw. So something basic is very straightforward. So that's how to build an interactive map by using the Lobbit API. Let's take a look at a more complex application. The bit is to region bibliography for the German state of Northrend Westphalia. It's cataloged by the three so-called NIV landis bibliotekens, so in the state of NIV we don't have a single state library, we have a distributed model of three libraries, and the presentation is done by Habit Set, and the new presentation is based on the Lobbit API. So let's take a look at NIV bit. This is a details page for one title, and you can see here's a map. It also shows libraries similar to the example before, just it's not libraries in some area, but it's the libraries with holdings of this particular title. We also have a marker, if we click it, in this case we zoom in, we get a link to the library and we get a link to the local catalog, but it's the same idea as before, we have a pop-up in the marker with some details. So something else that's interesting in NBibb is that when cataloging, for every title, catalog is catalog A subject location, so they catalog the area or the place that this title is about. So this one, for instance, is about Cologne, my hometown, and what now we do is we take these labels and send them to WikiData and get back the geodata for these labels, and based on that we can do many nice things. For instance, we can have a geosearch, so this is the starting page of NBibb, where we have these administrative areas. I tried once again, this is too small in this resolution, but you could search for titles that's related to places within these administrative areas, but it also allows us to have a sort of visualization of search results. So for instance, if we search for brown coal, we can see that in the east of NBibb, there are two single places related to brown coal, but here's a really big, then there are six places in Der Rugebiet, so there's a little relation to brown coal, but down here we see there are 42 places related to brown coal in the so-called Rheinische Brown-Kolle-Riebe, so we get really a visualization of our search result. We can also use this to search again as in the administrative areas in the starting page, so we can search for titles related to brown coal and places within this particular area. Ah, that was the wrong... The last wrong button. All right, so here we saw what a complex application with map visualization and browsing could look like, implemented in the way like the simple example based on an API, as I showed you before, in the simple examples. All right, so as a next application, let's take a look at Open Refine. Many of you know Open Refine, it's been mentioned a few times already. It's a free open-source power tool for working with messy data, that's what it calls itself. So it's based on a spreadsheet metaphor, so it's very familiar to people who work with spreadsheet software, it allows you to clean up your data, to do transformations, and to do reconciliation with external data sources, in particular APIs. So what this reconciliation means, we had a concrete use case with a user request of a user who had a list of libraries, where for every library had a title and a postal code, and for some, the ID in the National German Library Index. And what he wanted was a uniform identifier for all these libraries, and that's exactly what reconciliation is about. Sending your data somewhere, asking, do you know about this data, can you give me an ID? So let's take a look at how to do this with Open Refine and the LoBit API. So this is the starting, when you start up Open Refine, this is what it looks like, it runs in a browser, for those of you who don't know it, but you can write it as a local application, it's not like you have to upload your data anywhere or something, it just happens to use the browser. In this dialogue, we then open our data, it's a CSV file, Open Refine automatically recognizes it, it recognizes that we have a semicolon as a delimiter, you can see here that there are many supported import formats in Open Refine, you could tweak the import here, this is a preview of the import, it all looks fine in this case, so we just create a project. We now have this tabular data in Open Refine, and what we want to do is we want to reconcile this column with the library names with the LoBit API. So it works over this menu, but then we get a dialogue where we select the reconciliation API, we enter the LoBit API, we specify that we want to send the other data we have to improve the results, and what we get back is for every of these libraries, we get a list of suggestions from the API of possible matches with a rank. So we see here that for Stadtbücher-Reydenau, the best suggestion from the API is something called Stadtbücher-Reydenau with a score of one, and the other candidates have a very low score in comparison. Over here we see a visual representation of the quality of these suggestions, where we could remove the... we see that over here there are very few with very low scores, so we could move the slider and remove this bad data so we don't pollute our data with wrong identifiers. Now what we do is we create a new column based on this reconciled column, which we call a bit set ID in this example, then we use the Open Refine expression language to specify the value for this new column, for this new cells in this new column, and we say for each cell it should be the reconcilation result, the best result, the top one, and of that the ID. And again we get a preview here, we get these IDs, this looks good, so we create this new column over here where we have these uniform identifiers. No. All right. No. This is not working. That was this. Okay. Okay, so that was Open Refine Reconciliation. There are instructions, detailed instructions, if you want to reproduce this yourself. All right, so a little bit about what we learned in building and using this API. It's important not to lose any important data for your applications in the transformation to LOD when you process your original data to LOD. It's important to structure the data in a way that's useful for the application, so the application can send queries and process the response easily. And it's great to integrate into existing tools and workflows because if people use, for instance, Open Refine, that's the place they would like to use your data in. So the main lesson, the main thing we learned is really to let the applications drive the API into data design, to avoid premature abstraction, to support actual use cases before generalizing, or to put it in a different way, do usable before we use it. And doing usable is great because having other folks use your stuff makes your stuff better. So this is how we make progress, by building, using, and improving stuff. So a short note about how we built this particular API, we used MetaFacture, Elasticsearch, and the Play Framework. Short version is Java programming with open source tools, but all kinds of tools could be used to build an API like this. So now you might be thinking, okay, but what about linked data, semantic web, libraries, after all, this is a sweep? So one thing is that structured data that you saw, it is JSON-LD, it is RDF-compatible, it is linked data. But linked data and semantic web, I really know goals in themselves. They're a technological solution, one of many that might fit the real goals. And no matter what our role is, or our title, we are catalogues, developers, or managers. That goal is always the same, it's to make the product better for our users. And that product is software in libraries. And that's another possible meaning of sweep. So what's the thing to take away? It's really build APIs. We should build APIs, you should build APIs. They provide infrastructure for software in libraries. They make the great work of catalogues available for all kinds of use cases. That's why libraries need APIs. They empower yourself and others to use your data, beginning with simple cases as we saw in this question answering example, to build new applications as we saw in the visualization examples, and to improve existing applications, like in the Rope and Refine example, where you suddenly have this data in your application. It's not like it happens by itself, it's not like you build an API and then all these things happen. For these things to happen, it takes an API and some large but finite amount of work. But the APIs are the foundation. They provide infrastructure for software in libraries. They empower yourself and others. Thank you very much. Thank you very much, Fabiana.
 Thank you, David.  I'm just going to get the resolution right.  Okay, so hello everybody.  I have recently stumbled upon this poster by the American Library Association from 1925.  It advertises library work as the profession on which all other professions and occupations depend.  Now, I'm sure that anybody who does library work kind of likes that sentiment, I certainly do.  But at the same time, it makes you wonder how true that statement actually is.  Even back then, for instance, my grandfather was a baker.  I don't think he actually depended on library work.  But even more so, it makes you wonder how true that is today.  And I don't have an answer on that, but to the extent that this is true today, there is something else involved.  That software.  Because software is also something in which every profession and occupation depends.  Now, as the previous statement wasn't quite true, this also isn't quite true.  There are certainly professions which don't depend on software today.  But there is one profession which certainly does.  And that's library work.  Because libraries are software.  The services that libraries provide are provided directly or indirectly through software.  So this talk is called Lot for Applications using the Lobbit API, which stands for Application Programming Interface.  Now, why would we want to use an API?  Well, because Lot for Applications means building software.  And APIs make software development manageable.  They allow us to build modular software with stable applications where changes in parts of the software don't require changes in all the other parts,  particularly the applications.  At the same time, APIs allow us to have flexible data sources.  So let's take a look at what this means for the Lobbit API.  So through the Lobbit API, in the Lobbit API, we make available authority data from different sources in different formats,  geo data from Wickey data, and title data from our union catalog.  And all this data is made available to the applications through this API.  So the API really decoupled the applications from these specific data sources, formats, and systems.  So these systems, formats, and sources can change without requiring applications to change at the same time.  Because the API provides this decoupling.  All right, so the subtitle of this talk is Using the Lobbit API.  Now, what does that even mean, using an API?  So for web APIs, it basically means opening URLs.  So it's just like opening a website, but what we want back is structured data.  So let's take a look at how we can do this by using the Lobbit API.  We basically just open a browser in the URL bar, we specify we want something from our organizations API,  and then we search, for instance, for Habit Set, which is the organization I work for.  And we get back some structured data.  Now, in the address bar, we just change Habit Set, say, to SetBV, and we get different data.  So we're using the API.  Now, the idea is that the same URL we could use in a different way.  For instance, we can call that URL from the command line to get bike downloads, for instance.  So we can use Curl, and we can pass a format that we want, for instance, JSON-LD,  and we can pass that we want it in a zip form, so we have less disk usage.  And then we pass arbitrary queries in the form of a URL.  So for instance, we can get all the holdings of a specific library,  or we can get all new titles with a specific subject, and then we redirect this into the file.  And what we have is local data, which is ready for offline usage, but we still got it from the API.  So there is no contradiction between dumps and local data for offline usage and an API.  The API is just the means for delivery of that data.  All right, so let's take a look at a concrete application.  We can answer a single question like, how many libraries are there in Germany?  The traditional answer is 10,000, so is it 10,000, or is it more like 20,000,  which was an initial result we got when we asked and kind of asked our API this question.  So let's take a look at how we can do this by using the Lobbit API.  This is a single organization in our API, and we can see that there is a type field,  which says that this particular organization is a library, so this is something that we will be using,  because we want libraries.  And we have an address country field, which is nested within an address within a list of locations,  and this address country specifies that this is Germany.  So here we see the data, and based on this we can create a query where we say the type should be library,  and the location address address country, this nested field, should be Germany.  And in the result we get a field which specifies the total number of results,  so we have an answer for this question, it's 13,279 libraries in Germany,  according to our data and our API.  Now as I said before, this initial request, it said about 20,000, so what about that?  It's really that using a lot for applications, by using the Lobbit API,  we were able to improve the query,  so in the initial query we didn't consider the location,  because all our organizations in this API are German organizations,  but they are not all inside of Germany, like Gritte Institutes.  And we were able to improve our data,  because if your result is like the double of the common answer,  you send it to check what you're doing,  and we realized that we were taking into account inactive libraries.  So we really see that usage leads to improvement.  Alright, so let's take a look at a concrete application.  Say we want to visualize data on a map, like the libraries in Hamburg.  So let's take a look at how we can do that with the Lobbit API.  The starting point again is a query like before,  we say the type should be library, and the location address,  in this case we say address locality, not the address country, should be Hamburg.  Now our question was how many are there in Hamburg,  the answer would be up here, 153,  but in this case we want to use the data to create this map visualization.  In particular we want to use the geo-coordinate down here.  So a location has an address, but also a geo-location.  So to do that we create an HTML file.  In the head of the HTML file we integrate a mapping library,  we create a map down here,  and then we call the Lobbit API with this very query.  We say we want something with type library and location address locality, Hamburg.  Then we process the result down here,  and finally create a marker on the map using this geo-latitude and geo-longitude from the data.  And what we get is this, I try to switch to a live version of this.  Connection is too slow.  You would see that you can zoom in and out, you can pan around,  and you can click on these markers to get the name of the library.  This is to complete files for the result that you saw.  So something basic is very straightforward.  So that's how to build an interactive map by using the Lobbit API.  Let's take a look at a more complex application.  The bit is to region bibliography for the German state of Northrend Westphalia.  It's cataloged by the three so-called NIV landis bibliotekens,  so in the state of NIV we don't have a single state library,  we have a distributed model of three libraries,  and the presentation is done by Habit Set,  and the new presentation is based on the Lobbit API.  So let's take a look at NIV bit.  This is a details page for one title, and you can see here's a map.  It also shows libraries similar to the example before,  just it's not libraries in some area,  but it's the libraries with holdings of this particular title.  We also have a marker, if we click it, in this case we zoom in,  we get a link to the library and we get a link to the local catalog,  but it's the same idea as before,  we have a pop-up in the marker with some details.  So something else that's interesting in NBibb is that  when cataloging, for every title, catalog is catalog A subject location,  so they catalog the area or the place that this title is about.  So this one, for instance, is about Cologne, my hometown,  and what now we do is we take these labels and send them to WikiData  and get back the geodata for these labels,  and based on that we can do many nice things.  For instance, we can have a geosearch,  so this is the starting page of NBibb,  where we have these administrative areas.  I tried once again, this is too small in this resolution,  but you could search for titles that's related to places  within these administrative areas,  but it also allows us to have a sort of visualization of search results.  So for instance, if we search for brown coal,  we can see that in the east of NBibb,  there are two single places related to brown coal,  but here's a really big, then there are six places in Der Rugebiet,  so there's a little relation to brown coal,  but down here we see there are 42 places related to brown coal  in the so-called Rheinische Brown-Kolle-Riebe,  so we get really a visualization of our search result.  We can also use this to search again  as in the administrative areas in the starting page,  so we can search for titles related to brown coal  and places within this particular area.  Ah, that was the wrong...  The last wrong button.  All right, so here we saw what a complex application  with map visualization and browsing could look like,  implemented in the way like the simple example  based on an API, as I showed you before,  in the simple examples.  All right, so as a next application,  let's take a look at Open Refine.  Many of you know Open Refine,  it's been mentioned a few times already.  It's a free open-source power tool for working with messy data,  that's what it calls itself.  So it's based on a spreadsheet metaphor,  so it's very familiar to people who work with spreadsheet software,  it allows you to clean up your data, to do transformations,  and to do reconciliation with external data sources,  in particular APIs.  So what this reconciliation means,  we had a concrete use case with a user request  of a user who had a list of libraries,  where for every library had a title and a postal code,  and for some, the ID in the National German Library Index.  And what he wanted was a uniform identifier  for all these libraries,  and that's exactly what reconciliation is about.  Sending your data somewhere, asking,  do you know about this data, can you give me an ID?  So let's take a look at how to do this with Open Refine  and the LoBit API.  So this is the starting, when you start up Open Refine,  this is what it looks like, it runs in a browser,  for those of you who don't know it,  but you can write it as a local application,  it's not like you have to upload your data anywhere or something,  it just happens to use the browser.  In this dialogue, we then open our data,  it's a CSV file, Open Refine automatically recognizes it,  it recognizes that we have a semicolon as a delimiter,  you can see here that there are many supported import formats  in Open Refine, you could tweak the import here,  this is a preview of the import,  it all looks fine in this case, so we just create a project.  We now have this tabular data in Open Refine,  and what we want to do is we want to reconcile this column  with the library names with the LoBit API.  So it works over this menu,  but then we get a dialogue where we select the reconciliation API,  we enter the LoBit API,  we specify that we want to send the other data we have  to improve the results,  and what we get back is for every of these libraries,  we get a list of suggestions from the API  of possible matches with a rank.  So we see here that for Stadtbücher-Reydenau,  the best suggestion from the API is something called  Stadtbücher-Reydenau with a score of one,  and the other candidates have a very low score in comparison.  Over here we see a visual representation of the quality  of these suggestions,  where we could remove the...  we see that over here there are very few with very low scores,  so we could move the slider and remove this bad data  so we don't pollute our data with wrong identifiers.  Now what we do is we create a new column  based on this reconciled column,  which we call a bit set ID in this example,  then we use the Open Refine expression language  to specify the value for this new column,  for this new cells in this new column,  and we say for each cell it should be the reconcilation result,  the best result, the top one, and of that the ID.  And again we get a preview here,  we get these IDs, this looks good,  so we create this new column over here  where we have these uniform identifiers.  No.  All right.  No.  This is not working.  That was this.  Okay.  Okay, so that was Open Refine Reconciliation.  There are instructions, detailed instructions,  if you want to reproduce this yourself.  All right, so a little bit about what we learned  in building and using this API.  It's important not to lose any important data  for your applications in the transformation to LOD  when you process your original data to LOD.  It's important to structure the data  in a way that's useful for the application,  so the application can send queries  and process the response easily.  And it's great to integrate into existing tools and workflows  because if people use, for instance, Open Refine,  that's the place they would like to use your data in.  So the main lesson, the main thing we learned  is really to let the applications drive the API  into data design, to avoid premature abstraction,  to support actual use cases before generalizing,  or to put it in a different way,  do usable before we use it.  And doing usable is great  because having other folks use your stuff  makes your stuff better.  So this is how we make progress,  by building, using, and improving stuff.  So a short note about how we built this particular API,  we used MetaFacture, Elasticsearch, and the Play Framework.  Short version is Java programming with open source tools,  but all kinds of tools could be used to build an API like this.  So now you might be thinking,  okay, but what about linked data,  semantic web, libraries, after all, this is a sweep?  So one thing is that structured data that you saw,  it is JSON-LD, it is RDF-compatible, it is linked data.  But linked data and semantic web,  I really know goals in themselves.  They're a technological solution,  one of many that might fit the real goals.  And no matter what our role is, or our title,  we are catalogues, developers, or managers.  That goal is always the same,  it's to make the product better for our users.  And that product is software in libraries.  And that's another possible meaning of sweep.  So what's the thing to take away?  It's really build APIs.  We should build APIs, you should build APIs.  They provide infrastructure for software in libraries.  They make the great work of catalogues  available for all kinds of use cases.  That's why libraries need APIs.  They empower yourself and others to use your data,  beginning with simple cases as we saw in this question answering example,  to build new applications as we saw in the visualization examples,  and to improve existing applications,  like in the Rope and Refine example,  where you suddenly have this data in your application.  It's not like it happens by itself,  it's not like you build an API and then all these things happen.  For these things to happen, it takes an API  and some large but finite amount of work.  But the APIs are the foundation.  They provide infrastructure for software in libraries.  They empower yourself and others.  Thank you very much.  Thank you very much, Fabiana.
LOD_for_Applications_-_Using_the_Lobid_API___Pasca_rbQVpzQjIn0_0_71.png LOD_for_Applications_-_Using_the_Lobid_API___Pasca_rbQVpzQjIn0_72_1943.png LOD_for_Applications_-_Using_the_Lobid_API___Pasca_rbQVpzQjIn0_1944_2195.png LOD_for_Applications_-_Using_the_Lobid_API___Pasca_rbQVpzQjIn0_2196_4403.png LOD_for_Applications_-_Using_the_Lobid_API___Pasca_rbQVpzQjIn0_4404_4931.png LOD_for_Applications_-_Using_the_Lobid_API___Pasca_rbQVpzQjIn0_4932_11195.png LOD_for_Applications_-_Using_the_Lobid_API___Pasca_rbQVpzQjIn0_11196_13667.png LOD_for_Applications_-_Using_the_Lobid_API___Pasca_rbQVpzQjIn0_13668_15167.png LOD_for_Applications_-_Using_the_Lobid_API___Pasca_rbQVpzQjIn0_15168_15299.png LOD_for_Applications_-_Using_the_Lobid_API___Pasca_rbQVpzQjIn0_15300_15371.png LOD_for_Applications_-_Using_the_Lobid_API___Pasca_rbQVpzQjIn0_15372_20459.png LOD_for_Applications_-_Using_the_Lobid_API___Pasca_rbQVpzQjIn0_20460_20663.png LOD_for_Applications_-_Using_the_Lobid_API___Pasca_rbQVpzQjIn0_20664_20711.png LOD_for_Applications_-_Using_the_Lobid_API___Pasca_rbQVpzQjIn0_20712_23915.png LOD_for_Applications_-_Using_the_Lobid_API___Pasca_rbQVpzQjIn0_23916_24143.png LOD_for_Applications_-_Using_the_Lobid_API___Pasca_rbQVpzQjIn0_24144_25199.png LOD_for_Applications_-_Using_the_Lobid_API___Pasca_rbQVpzQjIn0_25200_25857.png