We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

How Linked Open Data finds the bar near you

00:00

Formale Metadaten

Titel
How Linked Open Data finds the bar near you
Serientitel
Teil
127
Anzahl der Teile
193
Autor
Lizenz
CC-Namensnennung 3.0 Deutschland:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Within the GIS community we became very fond of our web map servers and feature request possibilities to share and access data. Sharing data is relevant and applicable to other fields and communities. This led to the rise of the semantic web and to web 3.0. Clearly defined relationships between objects make it possible to interlink them and allow to search for relationships themselves. In this presentation I will demonstrate a web application that uses different techniques to access linked open data and show how the individual results can be used as input for the next search request. An open innovation platform on linked data was started in the Netherlands. One of their results was to open a server to store and access linked open data. I have used this data warehouse as a starting point for a demonstration in a geo web application. The application is based solely on open source frameworks (OpenLayers, proj4js, jQuery, and pure). The user enters a zipcode and house number, and the application uses linked data techniques to retrieve the location. This first search result connects to the next open dataset to obtain statistical information about the area. One of these statistics is the average number of bars within a 1 km radius. But where exactly are these bars? Using yet another open dataset (OpenStreetMap with Overpass API) we can pinpoint the location of bars and pubs.
MehrwertnetzSkalenniveauRechenbuchLinked DataApproximationp-BlockCoxeter-GruppeSchätzfunktionEinhüllendePhysikalismusRechenbuchMinimumWärmeleitfähigkeitArithmetischer AusdruckFokalpunktMereologieFunktionalPrinzip der gleichmäßigen BeschränktheitDifferenteFastringGüte der AnpassungComputeranimation
Linked DataAdressraumStatistikInformationDemo <Programm>VersionsverwaltungGeometrieFormale SemantikDatenverarbeitungssystemDatenstrukturGewicht <Ausgleichsrechnung>SchlüsselverwaltungTabelleVerschlingungIdentitätsverwaltungURLMehrwertnetzVarianzSemantic WebPrädikat <Logik>Objekt <Kategorie>BildverstehenSkalenniveauIRIS-TAbfrageKonzentrizitätSchedulingBenutzerbeteiligungInternetworkingDifferenteWeb-SeiteSchlüsselverwaltungDatenbankBitInformationsspeicherungRelativitätstheorieDatenstrukturMAPGeometrieDienst <Informatik>Demo <Programm>Objekt <Kategorie>SchnittmengePrädikat <Logik>Kartesische KoordinatenAlgorithmische GeometrieVerschlingungTabelleVersionsverwaltungAbfrageEindeutigkeitURLVirtuelle MaschineNatürliche SpracheLinked DataGanze FunktionFormale GrammatikPuffer <Netzplantechnik>MereologieWort <Informatik>Relationale DatenbankLesezeichen <Internet>Textur-MappingMinkowski-MetrikForcingAdressraumMaßerweiterungSchaltnetzInstantiierungSemantic WebCoxeter-GruppeOpen SourceRechter WinkelKategorie <Mathematik>Computeranimation
StatistikGrundsätze ordnungsmäßiger DatenverarbeitungAdressraumInformationMAPGebäude <Mathematik>Offene MengeOpen SourceAbfrageVarianzEin-AusgabeLinked DataPrädikat <Logik>Objekt <Kategorie>Minkowski-MetrikEinfach zusammenhängender RaumDatenstrukturServerMathematikGeometrieCodeDemo <Programm>Lokales MinimumFlächeninhaltMittelwertDiophantische GeometrieAbstandCAMIRIS-TSummierbarkeitNetzwerkbetriebssystemNachbarschaft <Mathematik>VierMehrwertnetzPrinzip der gleichmäßigen BeschränktheitFünfKartesische KoordinatenDemo <Programm>AdressraumDiophantische GeometrieFlächeninhaltGeometrieCodeGebäude <Mathematik>AbstandZeitrichtungFunktion <Mathematik>Objekt <Kategorie>DifferenteRadiusInformationMAPProjektive GeometrieSchnittmengeNachbarschaft <Mathematik>Open SourceBenutzerbeteiligungEin-AusgabeVerschlingungPrädikat <Logik>DatenstrukturDienst <Informatik>WellenpaketQuaderStatistikAbfrageAmenable GruppeOffene MengeTurm <Mathematik>Physikalisches SystemPunktZweiMultiplikationsoperatorInformationsspeicherungDatenbankPrinzip der gleichmäßigen BeschränktheitBitURLMittelwertÄhnlichkeitsgeometrieMereologieUmwandlungsenthalpieProjektivitätBildschirmmaskeFehlermeldungEndliche ModelltheorieGüte der AnpassungCodierungCASE <Informatik>AdditionAlgorithmische GeometrieFlussdiagramm
VersionsverwaltungAdressraumFibonacci-FolgePrinzip der gleichmäßigen BeschränktheitMehrrechnersystemKartesische KoordinatenPrinzip der gleichmäßigen BeschränktheitBitDifferenteDemo <Programm>URLDienst <Informatik>MultiplikationsoperatorVersionsverwaltungInformationsspeicherungNachbarschaft <Mathematik>SchnittmengeDatenbankAdressraumErwartungswertGebäude <Mathematik>CASE <Informatik>Coxeter-GruppeComputeranimation
HilfesystemSpeicherabzugMehrwertnetzCOMCAMMarketinginformationssystemMAPInformationsspeicherungMalwareGüte der AnpassungCoxeter-GruppeMultiplikationsoperatorAbfrageIterationUmwandlungsenthalpieRuhmasseComputeranimation
Computeranimation
Transkript: Englisch(automatisch erzeugt)
So, for the next session in this block, we have Rob Benlon speaking about how to use linked data to find bars near you, which is something we all tend to need to know how to do very often.
Well, good afternoon. My name is Rob Benlon and I'm going to give you a presentation on how linked open data can help you to find the bar near you. Now, with a title like this, you can start wondering why? Why do you want to do this? Why do you want to use linked open data?
And why actually do you want to find the bar? The linked open data part, I'll get to that during my presentation, but let's focus first on why do you want to find a bar? Well, my background is in physics. And one of the great names in physics is Enrico Fermi.
He was a very smart guy. He won the Nobel Prize and all. But he also had a very special ability. And that is that he could make rough estimates of very difficult calculations. And he was always, well, quite right.
So once they really did all these calculations and they got the final answer and they took his approximation, well, more or less it was okay. So you could say that his specialism was making calculations on the back of an envelope. Well, I'm also Dutch. And in Dutch, we don't have this expression, calculation on the back of an envelope.
In Dutch, the expression is a bit different. We make calculations on the back of a beer coaster. Where do you find beer coasters? Right, at bars and pubs. So if you want to do these kind of calculations, you have to find yourself a beer coaster. Therefore, you have to find yourself a bar.
Now let's move on to linked data. During my presentation, I'll give you a short introduction on linked data, tell you what it is, give a short example, also how geo is connected into this. And then I'll move on to this demo application that I made, which searches through addresses
over with a linked data store, throw in some map service to make a nicer picture, use some feature services to get some more statistical information, and in the end, use OpenStreetMap to find ourselves a bar.
This demo application is based on a Dutch data set. So for this conference, I also made an international version. So you can still find out which bar to go to. So linked open data. Well, let's first concentrate on data, or perhaps data on the internet.
When the internet was developed, there were lots of web pages that interlink documents to one another document to yet another document. And well, that's all nice for us humans. We can just visit one page, read what it's about,
interpret that data. And then we'll go on to the next page, you know. And on these web pages, there might be, well, an HTML table, there might be comma separated values. You might use your feature services, key value stores, relational databases, you name it. It's out there on the internet.
And as I said, that's quite useful for us humans. We can read and we can interpret that data. But yeah, not so much for computers. They don't really understand all that data. So luckily, we can help the computer by adding a universal structure to our data.
We can start by naming things. And with things, I mean, well, what actually is your data? And also important, start naming relationships between all your data. And don't just name them, but also identify them.
Make a unique resource locator so you can just link to that and you'll find your data back. And also, well, start using vocabularies. That means that you don't start randomly naming things,
but you think of a structure before and you write down also for humans what this data is about. And if you do all this, then we move into the semantic web, which is machine readable because the machine can then understand what all this data is about.
Since we have links to all the data things that we used and also links to the relationships between all the data, well, you can start interlinking all your different data sets and thereby also, well, include external links.
So if you do all this, the computer's happy. Perhaps this comes a bit clearer with a simple example. Link data uses triple stores. And when I first was introduced to this triple store idea, really, well, I got the idea of, say,
a kindergarten grammar where you have a subject, a predicate, and an object. So in this example, foo is connected to bar. Foo is the subject. Bar is the object. And the relationship between them that is connected to, well, that's the predicate.
Couple of more examples of triple stores, of triples. Rob, that's me, is a person. Rob works for Ordina. And Ordina is based in the Netherlands. And if I say the Netherlands, then I mean that's the same Netherlands as,
well, in that link. And DBpedia is a big attempt to get like the entire of Wikipedia and put that into a linked data store. So other people can say link to the Netherlands. And everyone knows we're talking about the same Netherlands
and you can interlink our datasets. We can then access or query these triple stores with a language called sparkle, which basically is just the SQL but for linked data.
It also has a select star or select some properties, where, well, and you have your where clause. Not very special. But what we can do, if we add an extension,
that's called GeoSparkle, you can enable, well, geo capabilities within your linked data. So you can get your favorite, well, as well-known text. You can use within or textures, overlap, buffers,
all your favorite spatial relationships you can use and query your data. So for instance, if we make a query, select, make me an overview of all the, say, people, country combinations,
of all the FOS4G participants, where the participant plays football or table football. And so we can make a, well, competition schedule perhaps. If you have to do this using relational databases, where all your data is in different databases
or different data silos, it's not going to be that easy. But with linked data, you can combine this entire search query in just one go and you'll get your overview. So much for, well, the short introduction on linked data.
Let's find ourselves a bar. I made this small demo application using open-source technology and open data. As the open-source technology, well, it's just HTML, JavaScript,
with some jQuery to tie things together, use some CSS to make it look nice, open layers three to put things on the map, and proi4 to handle with project transformations. On the open data part,
I use a triple store from Pilot. And Pilot is a Dutch pilot project on linked data. And one of the things they did is to open up a triple store and put there some, well, Dutch open data in there
and make that available with a sparkle endpoint. In this case, I'm going to use the addresses in that data store. Then I also use some other open data from PDOK, which is a very nice, well, data set of all kinds of maps from the Netherlands
on all kinds of subjects and stuff. Really nice. We're going to use information from statistical Netherlands, which is the statistical bureau of the Netherlands to get some information about areas. And in the end, open street map to find ourselves a bar.
So we're going to use the linked data store of Pilot to search through addresses. And in this web application, the user enters a simple address, zip code, house number, via web form, it's not very special.
And then we're going to use that and send a search query to the sparkle endpoint. Mind how the arrows are pointing here and they go from subject predicate to object. Once we have the address,
well, then we're going to start looking for all the public spaces that are somehow connected with the predicate has address to that specific address object. Once we find this particular public space,
we use that as a, first it was a subject, now we're going to use it as an object. And we're going to look for the subject with the predicate is connected to, to the object of public space that we just found. And then we find ourselves the residential object.
Then again, we use another link to get from the subject residential object to obtain the object of the building. From the building, we're going to make another search and get the geometry of the building and then geometry of the building,
we're going to output as a well-known text. So as an overview, this is what we did. Start with a search input from the user to just a zip code and house number. Found the object of the address that's representing that specific address.
Moves on to public space, residential object. Find the connected building to that. From the building, we went to geometry and so in the end, we'll get the geometry of the buildings associated to that specific address. Mind you, that's something different than just the location of the address. The location of the address would just
give you a single point on the map. This query gives you all the geometries of the associated building with that specific address. So it's similar but still a bit different. Two lessons learned here.
First one, don't do this. Don't do this unless you know how to interlink this data and know your data and the data structure. Well, luckily if you don't know the data structure beforehand, then SPARQL and linked data techniques
help you to really find out how this structure is to, in the end, arrive to the geometry part. And second lesson is, well actually, this is really where linked data shines. Making all these interconnections and in the end, you'll get the geometries
that are somehow linked to that specific address. You would be able to do this if you had access to the database with SQL but if all you have is a web feature service, well, it's gonna be tough.
But now, let's look at the demo application. The user enters zip code house number and we start the linked data search as I just drawn for you and out comes the building on the map.
This particular building is a bit of a special building. It's the church tower in Amersfoort and that's the zero-zero coordinates of the old Dutch reference system. I was there a couple of months ago
and in the floor there is this nice thing that says this was zero-zero. Just fun. User enters zip codes, house number and via linked data, we get geometry of that specific building. Then we basically use a web map service
to just draw all the other buildings in this neighborhood on the map. It's not very special. But then, we'll determine the center of the building that we got in the first place and get some statistical information about this area.
And what do we get? Well, the Dutch Bureau of Statistics gives you some specific information about that area and the name of the area, the number of houses, the number of people, the number of cars, distance to the nearest highway,
distance to the train station, all kinds of stuff. But also, you also get the average number of bars within a one kilometer radius. And in this case, 42.3.
And the first time I saw this, I first thought, oh, wow. That sounds like actually quite a lot, 42.3. But then, of course, quite obvious, the second question is, well, great. We find that there are bars in the neighborhood.
Where are they? Well, luckily, we can use OpenStreetMap with the Overpass API. It's very nice, and we can do a search query and give me all the amenities that are bar or pub for this particular bounding box.
Out comes the GeoJSON, which you then can plot on the map. So we can see the blue stars on the map. They're there. I was there a couple of weeks ago, and I can assure you these bars are actually there.
This demo application is, as I said, made on a specific Dutch data set only. And for this conference, I tried to make an international version. But unfortunately, I couldn't find a triple store
that has all the addresses of the world available. So no luck there. But luckily, OpenStreetMap to the rescue once again, because there you can search also for address locations, and they also provide buildings.
So we just use the locator of OpenStreetMap to find the location of where you're looking for. Then secondly, well, we use OpenStreetMap then again
to find the bars and pubs in the neighborhood. When I tested the application and searched for Bonn, I realized this is not gonna work. This is not gonna work because this is not enough. Remember, we are in Germany, and Germans don't do just bars and pubs.
There's also a beer garden. And you might laugh at this, but there's an important lesson here as well. You really, if you make applications like this, you really have to know and understand
what data you're expecting back from your, well, from your data service and how to deal with this. So in this case, we had to add beer garden. As a bit of a special for the Phos4g conference, if you search in Bonn, and for this conference,
there are a couple of bars that are associated with the conference, and well, they are presented with a OSG or compass instead of a blue star, just to make it clear. So in overview, I would say that linked data
is great for combining data sets, data sets that are perhaps on different databases and different services. You can just link them together. Linked data is also nice to publish and share your data sets with other people.
But that's a big lesson, as with the beer garden. You have to know your data and know what you're expecting. So I would say go ahead, find yourself a bar, and have a drink with friends. Thank you for your time.
Thanks, Rob. So do we have time for a few questions? Anybody have any questions for Rob? No? Okay. Thanks. Paul, we have to wait for, yeah, we have to wait 10 minutes. No, I have a question.
Oh, you have a question, ah. I thought you were ready to get up here and talk. I am, I am, yeah. So, apparently OpenStreetMap currently doesn't have like a sparkle endpoint. OpenStreetMap, no, but there is also an attempt
to pick up OpenStreetMap and put that into a linked data store. Yeah, because I think that would be a great opportunity also for this presentation to do that query in one sparkle query, yeah. And then, of course, I will pass the IPA is great, but for a specific collection of people.
Getting bars and pups and beer gardens, yeah. Okay, good. Any other questions? Paul isn't, Paul is with all the questions, he's next, so. Thanks, Rob. One more hand.