Open Belgium 2021: The base API for open data linked Data Event Streams

okay um quickly sharing my screen there we go thank you everyone for uh joining this session on linked data event streams and more specifically what i think is ought to be the base api for open data sets and this is really the base question that i've been asking together with my research team for the past time i i think already eight years and that's what's the best api to publish an open data set and i'm not the only one who tries to find out an answer or to find a question to find an answer to that question for example you have the the geospatial uh people that started with the wfs specification the web feature service that is the geospatial web querying api you have the linked data people that that started the sparkle endpoints and and and a query language that that can query over over uh graph data and you have many many many other specific apis that you can host over your data set but then of course from all these great querying apis which one do you host well if you look for example at flanders uh then then there's you have the address database they had they already have quite a couple of apis online like the um they about have 17 on their website and you can have a tool wizard to help you pick the right api uh that that you should start using to do something with the address registry but um if you want to look for a simple autocompletion functionality that's not included in the in the set of apis so um so so that that wouldn't work and right now if you if you ask them how much this costs to keep online these 17 different very specific apis they would answer that costs a lot even to maintain all these specific apis that costs a lot so this this situation where where on top of a data set you keep creating more and more uh apis that you that you keep try to keep uh that you try to keep up with with the recent trends um that is uh uh that is what i call a maintenance hell because you will uh just keep on creating legacy apis that need to be maintained a second fallback or like the fallback approach to to that is uh we will share a data dump and then if you're interested you can just create an auto completion api yourself on top of that data set and everyone is happy although with the address registry what we noticed is that for example um local governments started to create local changes to their own copy of the of the data set and they didn't go back to the to the master data set so in that sense we started creating out of date hard to synchronize copies of the of the data sets that that are maintained everywhere by everyone and by nobody at the same time and this is what i call the replication the i think these are these are two really big problems that we see when we try to to to design the the best api possible for for an open data set and neither of these two solutions is is is good because they both have uh have have problems so how do you define what your priorities should be when trying to publish a new data set well this is uh then the idea that that we positioned is that you should do as uh as as the the least amount of effort as as possible and the least amount of effort as possible is when you keep working with when you try to to get everyone to set up their own uh querying api but of course you need to be able to make sure that everyone can sync with the latest changes on top of your master data so that you really claim and advertise to everyone i'm the master source of this data and if there are updates in the in happening in the real world you should just come and fetch them from my event stream and this is uh this is i think the the new uh the new next thing that that we need to convince everyone about is to make sure that we do life cycle management across our objects uh that we do life cycle management for or uh for our data sets because that's and in this way we're going to make sure that this completion api is always going to be able to work on the last version this geospatial interface as well this linked data interface as well and so on and so forth but there's no specification yet for a stream of linked data objects and uh you may say well there's there's of course news feeds like like json feed or like atom rss and so on but i like the ideas behind behind these specifications but there are no linked data specifications they don't allow any uh data sets to to be uh to publish their latest objects towards the outside world so we designed one over the last last two years we've been designing this this interface it's called the link data event stream specification and we define a link data event stream as an always growing collection of never changing objects so never changing objects these are objects that be that that live that that live in a specific moment in time for example an air quality observation that an observation that once was made and you will never change that anymore in the in the future because that was the truth that that's at that point um you could also see it as version objects like a version of a specific uh suite name or a version of a specific address uh and and we'll make sure to uh uh to make that object and if you want to go back in time you will be able to find that object uh as it were at that timestamp so for uh for this interface we designed one with the simplicity of atom and rss also in mind and one page of such event stream contains a data description just like rss it contains uh links to other pages and it contains of course all the items in that page so so you can navigate through the through the event stream by just uh uh going uh following uh links to the thing if you want if you're a technical person you want to go dive deeper in this specification you can find it at w3id.org specification uh we're proud to uh announce that this is getting adopted by the cemec program at the european commission uh so this will really become a european uh specification for um for uh publishing linked data so with link data event streams you can just replicate the data and that's interesting but you cannot query the data then you can you can only copy all the data and if you would have a question like um give me uh all the air quality observations over the past 10 years you will just have to download all that uh all that all that data you will not be able to immediately put in uh put in uh give me an overview of the of the of the yearly summaries for example of that of that time series or give me all the exceptional results over that period of time that's also something that's not possible you actually need to download it and you need all to do all the processing on uh your own machines that's also interesting why because the right effort is happening or the right investments are in are happening at the right place for example uh if i uh i'm interested in a very specific uh processing of a specific data set then it's me who will have to invest in that in that in that processing and i don't think that should be the data publisher that should invest in my specific use of that of that data set but i do think that we will be able to um to grow towards a more efficient ecosystem where we all work together towards a more a better and more efficient uh data ecosystem where we share efforts of indexing data sets and this indexation this is what i think can happen with fragmentations let's look at link data event streams how do we go then in the end towards a specific geospatial interface i think that you can uh first just geospatially fragment that that link data event stream you can create styles from that uh from that event stream so that every geospatial tile also has an event stream in itself and if then for example you need to calculate the route from a to b then you can just download the right fragments of that event stream just in time the data will be uh will be less big to download it will still be a considerable amount amount of data to download but you will be able to download it just in time to answer your uh query as well and this downloading just in time well this is also interesting because that means that you can also do that on a server and if you do it on a server then you can also expose again this querying interface so i think i see a three level architecture that that that for for for open data apis in the future that looks like this at the core i see the link data event stream it's the it's the thing that if you don't do the link data event stream then you're not hosting uh a proper open data set i believe if you don't host the base open data event stream api then you're just cutting corners and you're not giving your end users the the flexibility they need on top of your data but on top of that link data event stream what you should do what you must do in fact you can do optionally you can build some reusable indexes yourself and this is the second tier you can fragment your link data event stream by geospatial areas or you can fragment it by um by prefix saying that everything with the letter a will be found in in that in that part you can also fragment it by time period you could say well i'm going to to first have all my data from this year is in that fragment while all the others are in the order and you can have many many other different fragmentations that you can uh think of these are indexes that can be created by you and yourself to stimulate the ecosystem of to reuse your data set but it can be equally uh created by uh third parties we will see in the in the the next presentation we'll see some interesting use cases where third parties may actually have good incentives to uh to do exactly that then uh on top of these reusable indexes only then i think that we will see querying interfaces for which you can if you really want to do developer enablements as a data owner you can for example host a sparkle endpoint you can host a wfs service a graphical interface a cypher interface whatever but i do think that these things are um are less stable if you if you do it as a as a data data provider yourself why because well they should always be a last priority to keep online so if they go offline i think people should always be able to fall back towards the reusable indexes and even if these go offline that they're able to fall back to the linked data event stream at the core good so this ecosystem then looks something like this this we will have multiple fragmentations which you can see as three structures on top of the event stream and then the for example the geospatial apis these are going to download the right fragments of the data when a specific question comes in but the specific apis will mostly be hosted by the third parties themselves we've all for these fragmentations we've also built the tree specification the tree specification is uh or the link data event stream specification is built upon the tree specification uh but they the 3a specification allows you to to fragment a collection of objects and you can specify different relations on top of your fragmentations like you can have relations concerning geospatial relations suffix relation substring relations time time based relations and so on and so forth that's it uh if this sounded somewhat interesting know that my team is hiring so this is my current team uh i'm looking for more people so uh feel free to send me an email if you're interested in doing something uh something with the link data event streams that's going to be the vision for the next four years of research um and uh that's it this was a very general and very abstract and very difficult uh introduction on link data event streams and three three and everything that we are doing uh in that realm but i want to make it more concrete and that's why i'm from from this moment on i'm going to keep my mouth shut and i have um invited way more interesting people than myself i have invited people that actually do things in the real world um so yeah without spoiling anything of their presentations i'm just going to give the floor to evan okay thank you peter also thank you for the invitation but it sounds a little bit that we are doing stuff in the real world and that you are doing nothing real important but i would say more the opposite but anyway let's see how i can get this working share my screen [Music] okay are you now seeing my screen not yet but i suppose it's coming oh well sorry i have to push another button it's working now we don't see it yet nope no okay for um for everyone uh in in the in the meantime yes now it's coming erin oh something moving uh and it stopped and airmen is gone okay uh we'll wait a moment it's crashing oh no you're uh you're still your sound is still here adam yeah crawl is crashing okay i know he's gone uh okay just uh just to um uh for the for the audience there will be room after all the talks to ask questions uh we we've foreseen quite some time for for questions to specific speakers so please write them down on a piece of paper or write them down in the chat uh we'll get back to them uh after uh after all the talks um yeah and we'll try to moderate that discussion then hi aaron you're back yeah a chrome crash about technical problems but now let's see if i can i will try to share my full screen right now and see if that's improving so it seems to take us some while do you see my screen now yes no it works where is yours okay great thanks sorry for all the technical problems um yeah so uh peter asked us to tell us a little bit about what we are doing in the netherlands um so uh together with walter uh uh we're going to to talk a little bit about what we what we did so far what our plans are and and motor will actually show a demo of the link data event streams proof concept that we are currently working on um so well my name is aaron fulmer i work at the dutch cadastral and also at the university of flint and in the dutch cadastra i'm leading the data science team and we are trying to to bring link data and knowledge graphs a step further in our in our team so at cadastral we have quite a long-standing history of of dealing with uh with link data uh i think the the first data set the key register anderson buildings i think we published already for more than five years that's what we call production linked data so it's really as a production effort it's available and you can use it and we also have this approach used for many other data sets around however we found out that that maybe last year that's well we had a lot of kind of problems in this this this flow of dealing with linked data especially we had a lot of data sets standing in the queue to be published by by us sling data but the team was not really capable of handling all the data sets because it simply took quite a while to publish data center's linked data we took several months to to publish this kind of key registers so we thought and also the technology was much more further developed at that time when we started five years ago we had to develop a much of our own tools but now a lot of improvements have been made in the link data tooling at least so last year we set up a new approach can we make link data more easily more cost effective so that it doesn't have to take months to publish a key register of linked data but can we do it within maybe five or ten weeks but it's much faster and and much simpler in in tools and well we kind of succeeded so now we publish the new key registers with this new approach and in january or february we released a buck 2.0 so the key register uh also building again but now a new version and now it takes us only five five weeks to publish this kind of uh large key registers so and also the the key ranges of topography uh large scale topography is also published through this new link data what you call registration architecture so you see that the links over here so how does this uh i won't go into details in this 10 minutes but basically we get the data from a postgres database and then we have some very simple uh tooling software components like the enhancer and the microservice and they will load in the end the triples into the dbe triple store and then we put a different views apis on top of it most relevant for our new approach is that we actually kind of divided the the linked data into two parts so we have what we call the registration view this is the lower part uh sorry for the dutch by the way in this slide where we just publish a data set as is as linked data as where the data model looks as much as possible to the original data model of the not linked data set and then on top of it we put the knowledge graph where we do get a kind of object view on the data where we integrate the data from the different data sets below but we also get a more customer friendly view on this data and in line with the previous picture and on top of this knowledge graph he put all kinds of apis on top of it for the different kind of of users that we have so this is now working quite okay so why then are we now moving on and also participating in this linked data event streams approve concepts well um we believe that it might be one of the the apis that we put on top of this knowledge graph infrastructure and also on the data set um we have to find out of course it's just the first steps but basically already it's it it um it also fits with the with the ideas that we have that link data should be much more cost effective and much more simplified in a way so there we have already a good connection i i think with what we also have to find out okay so then it might fit it might fit in the tactical architecture but for what kind of use cases does it really make sense to use this approach um so we have to find find this out and finally we also find it very interesting uh i think we can work much more together as as belgium and the netherlands and to learn from each other we are dealing with the same kind of data same kind of stuff so uh so we also see that a very nice start of collaboration between belgium and the netherlands on this topic so um but what did we do already then on this sling data event streams and so that's the point in time that i would like to hand over to uh to water water can you show us what we did so far yeah thanks uh aaron and let me see i'm going to share my screen if it's okay you can now see the triple store at specifically you can see the two data sets that we currently expose through the ling data event streams so that is the the key registry large scale topography bgt on the left hand side you can also see that these are fairly large data sets so this is the bgt logical topography key registry is over 1.3 billion triples and we also have the base registry of addresses and buildings or bach bag and that is 850 million and slightly over 850 million triples so these are relatively large link data sets around 1 billion slightly below slightly over 1 billion and of course we want to expose them now using linked data event streams we did an implementation of link data event streams which is currently here running on on localhost so this is basically the implementation where i currently configured the bag so the base registry of addresses and buildings and then i can search for different times so we implemented the time index and i can then when i change the the date i also get a different different part of the of the key registry back so this is say the low level api i can also because it's jason ld i can also easily put it in our triple store and then in the context of a triple store it becomes a little bit easier to process of course what i just showed you was really the raw json endpoint and then you can also see a little bit of the structure like how the data is fragmented into different uh different nodes that are part of the same bigger collection and specifically for our key registry this is one of the nodes that you can then retrieve the nodes have relationships to other nodes and those relations are semantically qualified so you can go for a less than or equal to relation but you can also go for a larger greater than or equal to relation so the pagination is basically semantically meaningful which is one of the key innovations i think of linked data event streams you can also take a look at the incoming node so the incoming node is then the the key registry collection uh which gives you in this case 10 members and so those are for black sofia object places of residency in the netherlands and these are this is actually the content that is part of the of the key registry and so in this case we are looking at something that won't see so this is a place of of residency not like a store or not an office space right so this is really great it's now running on on localhost as i already mentioned it took us only one sprint to implement and our sprints in the cadastral data science team are three weeks so in three weeks we were able to to implement it comfortably also able to give some feedback on the on the link data event stream specification so i would say it's a very good specification and it's very easy to implement in the next sprint so the next three weeks we will make this part of our standard way of exposing the key registries this means that in three weeks from now it will no longer run from localhost it will actually run from the online triple store and it will be one of the ways in which our key registries will be disclosed now one final point that i want to make here is that if you expose things over this amount of triples you don't need to use any memory you can actually use very low level means to expose the data so it's also a very cost effective way to publish such very large key registries that's the demonstration of what we did how easy it was and i would actually say everybody should do this this is a great way to expose your data as ling data evan did you have some closing words i otherwise i'll give it back to peter no i have no closing words so this is it this uh yeah this this uh makes me very happy this is uh this is the first uh uh or one of the first uh of a few uh first implementations of the linked data event stream specification i'm very happy to see that it's that it's easy to implement for for data publishers even if even if it's the first time looking at the spec um so uh so yeah when when do you think that that the audience here will be able to to download the entire bgt and the entire bag so all the addresses in in the netherlands um for as a link data event stream would that be before before the end of the month will that be before summer can you already make some some guesstimations can i answer this to evan yeah okay yeah so uh next print so that means the sprint actually starts today at the the new sprint so it means three weeks from now we will have the public endpoints available which means that you can basically go to the to the data sets that were also communicated in the chat and then if you go to slash feed so that will be our new standard path to expose link data event streams if the data contains a time dimension then it will have this slash feed path like you have sparkle or slash graphql you will also have slash feed and of course you should be able to walk through all of the data it scales very well even for these large key registries of over a billion triples yeah i would say april first and if you don't make it then you can always say it was an april first full joke that's a good one and we're always on the safe side yeah definitely but but happy to hear that it uh that that this means that if i if i add some buffer that certainly before summer there will be an uh a new uh uh new http points where you will be able to uh fetch all the data uh and and make your own intermediary indexes on top of them um there's a small question by by retimer on in in the chat uh whether these ten objects they were the only changes at this point of time or was this just subsetted and i think this is just indeed a page of uh so if you would follow then if you would go to the next page you will see more objects and that may have changed at that time uh so you always need to uh download more pages than just the the last base page i think yeah um good so uh let's move towards the the presentation uh of uh yeah because it's a bit weird to kick off at open belgium with with the great presentation by people from the netherlands so let's see let's show that in belgium where we don't have to uh to to be shy and that we can also do great things in in belgium itself and uh immediately from from uh from the most beautiful city in belgium as well uh so yeah no i will probably get some comments in the chat as well but uh uh one of the most beautiful cities in in in in flowers and belgium of course is ghent and uh olivier uh you're uh you're doing a great project there right i thank you uh pizza first of all thank you for having me uh peter so i'm olivia vandenslaugh um i'm so strategist at design museum kent i previously worked at memo and before that that was still packed so the center for um for expertise for digital and that digitalization of cultural heritage and now i'm working on a big project called the collections of ghent maybe first of all i'm not a developer i'm an art historian and curator um in background so i'm not the technical profile in the panel but nonetheless i'm going to try to give this presentation for you just try and share my screen i also have an error [Music] um please elaborate on your error uh if there's something we can help you with yes let's try it if it's the screen test permission for access at the screen is not given yeah it's your browser you should normally uh be able to to give access so if uh hi uh boris from cloud68 here olivier if you can go to the top side of your browser where the url for the page is on the left side of the url next to the flashing microphone you should have an icon with i guess i can describe it as two squares on top of each other yeah so you're going to want to click on that and it should say on the screen a pop-up will come up and on the screen share it might say temporarily blocked is that the case no i don't see the same icon so what browser do you currently have a chrome working uh perhaps you can upload it as a pdf olivier is that a a possibility yes then you click on um the plus actions in the left corner and then you should get the option to upload a pdf park could sell it to pizza if you want to um can you open your shower screen because there's video in it yes that's uh that's possible so uh where did you send it or send it to brecht as well i already have it soon okay can you share it yeah there we go olivia floor is yours yes next slide please so yeah okay i'm just gonna let the video play okay it's a new sound is there no sound so if youtube video you can share it directly uh by going to the plus icon and pasting the link of the youtube video there but when screen share uh there is no sound coming from your computer it's directly right sure okay yes that's that's in brief a very big project we're working on um right now next slide yes what the video isn't saying is here um so opening up the shark account and we're doing so um it's linked open very important uh usable data and connects to an uh interoperable image and asset and but we're also making it open so it's not just creating so so um it's not us just creating cool things but we also want to make sure anyone use it and use it in their own way next slice so opening up isn't enough um we started the whole project uh with the basic idea that they're already um a lot of cultural data sets out there but they're um always connected to each other or they're isolated and if they're not published already they remain in these closed silos all governed by each um institution on their own all following their own logics they are not really interoperable um from the start um so next slides um so what we want to do at heart at the core of the we want to first of all and connect and filter collections from four museums uh so we have uh some um industry museum uh design museum we also want to add an archive to the pool that's somewhat new because they all in themselves use a different standard to describe their data so that data is also registered in a way which also makes it hard for them to connect or communicate unless we try and translate it into one standard but then we want to take it one step further we also want to allow history to be to be published in that same data set or in the same day stream and so we're looking at how people can crowd harvest our crowd sources and their objects but they can also use the same model to do so and so everything becomes interoperable and everything can be queried without distinguishing whether it comes from an established collection or from a citizen of ghent i want to also create new heritage um so we're talking about data event streams and um i think the the big idea here is that heritage isn't static um so why should i be um if you look at people are registering today um in museums they do so um static so if something changes um let's say where a piece is in the depot or it's on this place somewhere or in an action space um the previous data always lost certain and it's very hard to retrieve unless you start working with backup and so we were thinking about together with what if we would start thinking about cultural heritage or to try to approach them as being time series what if he would be able to um have one single truth but having that that allows for a multitude exposed change as well and maybe next slide so we have we can publish cultural heritage objects by using um the caching headers or by making sure they're all time stamped we can done so uh go back in time and that would allow us um to create new applications with them we could uh track where this was through the time we could also track how a description object changes maybe because the creator on working on it um but also i mean try to do that with um value um that has been used by the registrar next slide please but of course it's not enough to be useful um for the people or for the questions already working in cultural heritage institutions but would be interesting we can try and figure out what the domain of cultural heritage uh could um so we're working with also cool tools which is a new um application file that's um by flanders and it's part of a bigger set of standards um and we're using that subscribe or to form our cultural heritage data too but we also have to put things on top of it which is called records in context standards because we're also working with archives and also at this point in time does not um ready allow for um describing archive and the third uh big framework we're working with is triple f which is the international um imaginability and framework next slide by doing this and by publishing a data stream object that has both texts coming stand a few but also making sure that um all the possible reproductions are um in there and you can query them in time we want to authenticate them reuse and we're starting several organs or several let's streams of funding um also in the project one of them is a financial scheme where we can um 200 000 to subsidize uh let's first let's have startups to reuse the data and make a new application but we're also starting a cultural data lab where we want to explore together with the cultural heritage professionals and the end users and what we can do with that data which will be in the next slides so this have the the technical architecture we're using it i'm not gonna really um go deep in this but as you can see it has two major components it's coming from uplift the cms so it's a collect management system where they are registering all the data um text from an object and then we also have all the images um that describe the objects or productions and and we are trying to um put them all the same data stream which we will then publish via a triple store which for this and the virtuoso and from there on people using uh sparkle queries to query the whole data set of all the entire objects both originating from the cultural heritage professional as from the um citizen from ghent and um try and encourage reuse from that and we will also build an immersive room that will feed also today data event stream as a kind of demonstrate of the the technology we're using um so thank you my presentation all right cool olivier so uh so there's a big project the cogant project that's uh that's going to uh to publish by summer as well going to publish a lot of collections so really the raw data the the the core data of of the museum in ghent five museum i think are are going to be uh published as open data um there this this open data will be linked data thanks to oslo culture so oslo is the open standard for linking organizations in flanders which is a data standardization initiative uh they set the standard for for uh cultural heritage and um and it will be used uh to uh to to make sure that that that everyone can again uh create derived services and create derived indexes on top of this uh these data sets and also within the cogent project which is really a big project with a lot of different partners we're going to make sure that link data event streams there make sure that everyone always has the last version of the of the of the data and that they always have all the flexibility they need to do anything that they want with the data and this is really important and i think that's really the driver um behind every linked data event stream so um so thanks a lot uh olivier for for that presentation uh we're a little bit behind schedule a little bit due to the to the technical difficulties uh that that we had i hope we will be spared from technical difficulties uh for the next presentations um the next uh speaker is brits loneville uh brit are you there yes i am super can you try to share your screen and and let's hope that it goes uh more swift than uh okay [Music] are you looking for the buttons or do you find the buttons yes so uh good afternoon everyone my name is brit londonville and i work at flanders marine institute also known as and i'm part of the data center working on the marine regions project and so today i'm going to present to you the marine region's gazetteer let me first introduce you to our wonderful team so we have landscapers which is our team leader and myself we are the two geographers of the team then you have salvador and patricia those are the two biologists of the team and then finally there's bertrand from it who is supporting us in every way he can with the i.t related stuff now what is marine regions all about uh let me try to explain it to you by using a a very recognizable case um meet mora moro which is a deep sea fish and this deepsea fish you can find it around archimedes sea mount in the mediterranean sea now let's say you went out on a dive and you saw quite a lot of muramuro and you want to talk about this to your american colleague so you call him up you say man i saw muramuru around archimedes mount and he starts laughing his ass off he asks you whether you were on drugs during this dive because no way that muramuru can be found around archimedes sea mount and you're definitely mistaken so what was your crucial um mistake here well you did not go to marine regions.org because if you would have gone to marine regions then you would have seen that there is actually two archimedes sea mounts um there's an archimedes man in the mediterranean sea and there's an archimedes sea mount in the north pacific ocean and so what is marine regions or how does uh marine regions come into this story well we try to improve um access to and clarity of marine geo-referenced place types names and areas and we do this by giving each unique geo object a geo object or an energy id so in this way you can clearly see the difference between archimedes cement a and archimedes seamount b that's not the only thing we do we also provide you with the coordinates of course a latitude longitude a bounding box if that's available even if there's a wms linked to this data we can show this on a small map um we're also going to give you a little bit of contextual information uh through the place type this will tell you is this a c mount is it a sandbank or you're looking at something completely different and of course we'll give it a name and now two objects can have the same name but of course one object can also have multiple names and multiple languages and we will also store all of this information our database and of course we're also going to provide you with the source where did we get this information um marine regions integrates a lot of other authoritative gazetteers such as the jepco gazetteer of undersea feature names but we also have created some data sets our own um such as the maritime joe or the maritime maritime boundaries geodatabase containing exclusive economic zones territorial sea so we have included all this information in the marine regions gazetteer as well and finally a very important feature of our gazetteer that i have not talked about yet is the relations because we have a hierarchy in our gazetteer with parents and children so we're going to link objects to their parents and and this way you can easily go through this hierarchy and and learn about marine regions objects now how can users access this data nowadays so what is the current state uh there are several ways to access this data you can just go to our website to the search page you can browse through the hierarchical browser so through the parent children relation for most important data sets we also have ogc web services wfs wms or we have rest services on our website and then we also have a marine uh regions r package so m regents um if you want to check that out so that's the current state um but as we have heard already from our from the people who were presenting before me we can do more for our users and our users include among others big uh geographic databases such as worms or urobus or using marine regions and so in order to go one step beyond what we have been doing so far um we are currently involved in a project with uh the team of peter with harem delva and also uh with the vlis open science team of mark porter and so we try to open up this data even more make it even less ambiguous um by um yes opening this data up as linked open data basically this is a six month project we are currently at the end of month number two um and so um what we have done until now is trying to link all our data to vocabularies to make sure that um it's very clear what we are describing in what way we are describing and so that everybody um and especially divers in the mediterranean sea can then clearly explain to their colleagues where they found their fish thank you very much for having me and i hope this was clear for everyone thank you a lot brett for the for the uh very swift uh presentation and it's it's it's uh i really like i already forgot the name of the fish but i really like the the the example you you give here i gave the arabic but i i feel it i have a hard time to to identify with the case that i would uh would be scuba diving in in in in a warm mediterranean uh uh atmosphere somewhere yeah that that's something for uh for poscoruna i think uh to to look forward to um uh i find it really interesting these three presentations there like like the first presentation was about address registries the the this and topological uh topographical help me out uh topographical right uh uh uh registries uh the second one was about uh about cultural heritage which is something completely different and now the third presentation was again about something completely different and still they're just a collection of objects that can be uh be managed as a link data event stream and this becomes really interesting that we can start build to build uh tools that just work uh across all these things at uh at the same time and speaking of a tool that can uh work on top of these three different things and is generic in in in that sense well that's something that brett is now going to present brett thanks peter should be loading can you see my screen yes okay so i am brecht from id lab gans and i'm working on the link data event steam clients the lds client in short and so what does this do this is being made in the the core hand project um like if you already said you have a few museum partners in gans that are publishing data so these are like the data providers and what you want is to build services on top of that for example olivier wants to build a dashboard to see what's the statuses of the institutions how many data they have published and if their mappings are correct etcetera or another service or application is the enrichment application and you want to add a link in the metadata from the object metadata to the image itself or to a presentation manifests following the f specification that that describes how the the image should be displayed another application would be a text search index and so that users can easily find objects by by typing in a search bar and of course to do this you need to harvest data from these institutions to your application and to do this i'm creating the lds client which is simply a harvester of linked data event streams and so that you can copy the data into your database system now you've maybe have been wondering don't we have oie bmr a difficult name to do that which stands for the open archives initiative a protocol for metadata harvesting so it sounds exactly like that and indeed it does similar things you have a data provider with metadata and a repository and on the other side you have a service provider which runs a client-side application called harvester also that performs certain requests over the web and receives an xml encoded metadata about the things and to do this it has specific request types and for example a verb list records give me the records from after this time okay we have this but uh what do we need now like this yep martin is invented in 2001 and yeah link data didn't exist at that time actually so it really needs an update to to be more um performance um for example it returns it works on xml nowadays people don't work a lot in xbox it still exists a lot but we have we already have json now and we have linked data more coming up like json ld so we need to go a step further there also it uses hard-coded requests and now with data event streams you have a more hyper media driven approach and you the client needs to follow relations to new documents to new nodes and these relations can be used spatially or in time based so the client and the server becomes more loosely coupled and you can even use indexes to publish the data also or epm is focused on the retrieving the latest version of an object while with event streams you can maintain all the versions yourself and choose how [Music] when you will drop older versions for example you will only maintain one year of data and after that people should have harvested already in their archive so you can set some retention policies how long you will maintain certain versions also with the server and who ie works with the resumption token this means that um um every client is like like served separately with the token and the server needs to process this token and then give them the next objects well with event streams you have cacheable fragments every document is the same and this means that it becomes very lightweight for server to host these so all these things are our ideas that have been evolved in the in the last 20 years and are now applied in the ending data specification the lds client is available on github you can find link here it's implemented with an actor-based architecture and it's a new architecture communicates calls that we've been developing in id lab it's a query engine um focusing on query over linked different link data sources and you can find the installation or the instructions here in the actual init lds client package and you can use it as a command line interface or as a javascript library so let's now take an example for the cohen project we have published data of design museum camps in this link now i want to retrieve all the data what i can do is for example given mime type i want to retrieve it in jsonld this here is the context i want to apply it on for example it can be a translation in english and on i want to only harvest after this time after january the first this year want all the data from there on and then the url to your event stream now to see this live in action i've run it here in my command line um with these parameters and now you see the the objects on the event stream are like floating in so i can process these in my system and create my own services on top of it so feel free to try it out in your comment line i would say and if you have questions i would like to hear it afterwards thanks thank you very much indeed really nice to see that the history from oai pmh uh towards uh uh towards link data event streams and that we indeed do the same have the same idea in mind but that with that or solution is is more tailored towards http unlinked data and and really brings it into the the into 2021 instead of uh the 2001 uh version of the of the specs so uh so uh so really interesting work um uh just maybe a side note that that it is uh alpha version code we we're sharing this code now for the first time at the at a conference so uh uh please open a lot of issues when you when you encounter onto the issues with it i i pasted the link in the in the chats towards the the link data event stream client um please forgive us if something goes wrong please open issues and we'll try to fix them as soon as possible and give it also a second chance if you're uh if you're able to do that um with openness comes also a little bit uh of of uh you cannot you cannot publish as uh early enough but on the other hand you only lose you you only have one chance to make a first impression and these two things need to be balanced well i try to balance them by uh by adding that a side note here so i like to release early but then please forgive us if there are still mistakes in it um good uh the next presentation is uh by uh shorts who's again from the uh from the northern neighbors um shirts can you hear us can you can yeah and there's my website okay perfect so uh uh feel free to take control of the presentation yes this is going to be hard of course the previous experiences having the previous experiences in mind yeah it appears to be an iq test or something by which i don't mean that okay no i think there it is share all right the famous question can you see my screen at this moment we cannot ah wait okay it's loading now yeah now we can get slow all right in a few seconds there it is yes there it is perfect it's perfect my name is george valk i'm involved in the dutch digital heritage network and i'm going to talk about auto completion which is a very specific use case for using or potentially using linked data event streams so this is not a talk on the perspective of a data publisher but more of a data consumer first off the dutch digital heritage network is a partnership founded in 2015 um a partnership of dutch cultural heritage institutions in the netherlands of course and our aim is to develop a system of national facilities and services for improving the visibility the usability and the sustainability of digital heritage and one of these national facilities that we are working on is called the network of terms and i'll explain this in a little bit but first off a little bit about cultural heritage this is a painting a rather unknown painting i have yet to meet the first person that knows who painted this painting it's called the drawbridge in new amsterdam this is actually painted near the place where i was born which explains my rather grim nature probably and if i show the next painting then you you'll probably know who painted this one this one is called almond blossom and the creator of this painting of course is vincent fengo um however there are there is a problem uh two institutions in this in this example own a painting of fengo on the left-hand side and on the right-hand side both institutions use different terms to refer to the same information in this case they use different notations to refer to vincent van gaal for for instance written as vivengo or vincent fingo this of course is a problem for findability because people know that vivingo and vincent van gogh actually are the same person but machines do not unless you tell them so so of course we can encourage institutions to use the same terms to refer to the same information for example vincent van gogh easy right yes but then there's another problem the problem of identity of course vincent van gogh as we know him is the this famous painter but there's also another vincent van gogh his nephew who has exactly exactly the same name so how can you distinguish between these two persons of course link data officer solution we can use identifiers uris to refer to this one creator of these paintings these uris stem from what we call terminology sources and here are a bunch of them and terminology sources is basically an umbrella term for for fisauri classification systems reference lists authority files etc there are national terminology sources but also international terminology sources you may probably know a couple of these so we want to encourage cultural heritage institutions to start using terms from terminology sources especially to start using uris to revert to terms from terminology sources in order to improve the findability of their information but then new problems arise of course user applications such as collection management systems can connect to the systems of these various terminology sources but these systems use different api endpoints for example a sparkle endpoint or some custom web api and these terminology sources use different data models for exposing their information and this makes it rather hard for user applications to connect to these sources because they have to understand the various api protocols and the various data models of these various terminology sources and this hinders of course uh the easiness with uh which for connecting to these sources though we conceived a solution and this solution is called the network of terms this is an application that is basically a gateway between user applications such as collection management systems and terminology sources so user applications do not have to connect to the systems of terminology sources anymore they can connect to the network of terms or to the api of the network of terms so a user application can send a search query to the network of terms the network of terms then repackages this query and sends it in real time to one or more terminology sources in parallel then collects the results of these individual sources repackages them into one result set and returns this to the user application and this one result set contains the matching terms um including of course the crucial uri that a collection manager can then store in his user application or in this collection management system the network of terms offers a uniform api so that user applications do not have to know the specific api protocols and data models of the various terminology sources the api is working perfectly but it's rather hard to show this to collection managers or less technical people so we also developed a so-called demonstrator a rather simple visual interface that you can use for filling out some kind of search query for example vincent van gogh selecting one or more terminology sources and when you hit the search button then this demonstrator calls our own api searches the sources and presents the results this is also working perfectly but there's one problem one big problem users do not want to fill out an entire search query in this case vincent van gogh users are lazy collection managers are lazy so they want to have some kind of google-like experience that if they start typing then matching terms should pop up instantly in this case vincent go so how can we add this feature this functionality to our network of terms in a way that makes sense that fits into our architecture we could of course put into place some kind of autocompletion server this server would then harvest data from all the terminology sources and stores this in some kind of index then user applications would be able to query this autocompletion server this however doesn't really fit into our our architecture because it's not a decentralized solution it's a centralized solution you would have to collect all the terms from all the terminology sources into one index it's not a really scalable solution because in this picture there are just three terminology sources but there are a lot more and this is uh ever growing so our auto completion server would have to grow too and this is not a very lightweight solution our current network of terms implementation is lightweight because it directly queries the sources um but this autocompletion server would force us to maintain the data that we harvest and re-harvest it periodic periodically in order to keep the information current luckily we stumbled upon something called tree and of course this has been explained before and three offers a solution for our auto completion uh problem so we teamed up with id lab with peter and uh and harm delpha and asked them to develop a prototype for us that demonstrates uh the auto completion functionality for us using the tree vocabulary and what it basically looks like looks like is that there is a terminology source this terminology source publishes its terms its data as rdf this is rather common so this is not really new this is something that most terminology sources in our network already do this data gives us the opportunity to introduce a new component the so-called fragmenter this fragmenter grabs the data and creates lots of tiny fragments of the original data file of the original rdf data file and for auto completion this basically means that a fragment for instance in the case of vincent van gogh consists of the v of van gogh this v has a relation with the a v a n etcetera so you can build up an entire tree of relationships between characters of terms so in the end all terms all the parts of terms have their own fragments have their own fragment and this fragment basically is just an rdf file a very small rdf file that an rdf file nonetheless then there's some fragments server because all these tiny fragments in itself do not do anything you need a server to make these fragments accessible a fragment server so uh interestingly uh the data uh the the the source data must be provided by the source if you cannot do this and then you're not a really good data publisher right um you can of course uh provide some kind of rdf dump however uh and this is of course the interesting interesting part you could also offer your data as some kind of linked data event stream so that becomes a continuous stream which would then fit into into a pipeline where as soon as updates arrive from a terminology source for instance a new term has been added the fragmenter could recreate or create a fragment of the new term and then make it accessible for the fragments server to serve it to whoever is interested in these fragments the other components the fragmenter and the fragment server however can either be provided by the terminology source if the source has the resources for maintaining this kind of infrastructure or a service provider can do this and this fits rather well into the picture that peter painted at the beginning this is the tier approach there's something that you must do yourself as data publisher and there are things that you can do but also things that other people or other parties can can do for you this uh that this is all good but there's still no auto completion functionality right we have a bunch of fragments and a fragment server but that's it so there's we we need more than this so the fragment server the fragment server are very very simple servers they just serve plain rdf files to offer this autocompletion functionality we need an autocompletion client and this is a smart client it knows how to request fragments from one or more fragment servers it knows how to interpret the data inside these fragments and it knows something about autocompletion for instance about ordering the results ordering the terms in some kind of a fashion that makes sense for autocompletion um interestingly uh uh tapping into what breth already mentioned this auto completion client too has been developed using the communica framework um so our auto completion client is not it's just a simple client it's it's basically a small a query engine that understands the vocabulary that we use for making autocompletion work at the end there's of course a user application or as peter mentioned in his talk an awesome application this is the part where the user interface resides this is where end users for instance collection managers of cultural heritage institutions work and this is where they fill out their search query where the autocompletion functionality starts to kick in and the user application operates the autocompletion client which then queries the fragments server or servers and there we have it autocompletion functionality but what does it look like in practice we also asked idealab to not only develop a prototype for the fragments fragmenter and the fragment server but also a demonstrator official interface in order to show the results so that actually works and this is it you can go to this uri and try some some terms yourself that this demonstrator currently searches for sources for quite different sources for instance the cultural heritage resource and the second world war a world war ii thesaurus so this is my query f-i-r and it's uh it results in terms like fur first fires firewalls etc uh is there something special about this demonstrator no this is this is exactly the functionality that you would expect of an autocompletion function right a search bar and autocompleted results um so from an end user's perspective this is precisely what we want uh however underneath it all there's this fragmenter there are these fragments there's the three specifications there's a link data event stream hopefully eventually in place for making this work and this fits perfectly into our architecture of having this decentralized approach with linked data as the core method for publishing and using data so what's next this is a prototype so we need to test it thoroughly for instance we want to measure performance especially user perceived performance is it good enough for users to use and another perspective is what is the exact quality of the autocomplete terms so we need to look at the contents of the of the terms that are found if this is all successful then we would like to bring it into production uh we don't know yet when but probably uh uh thinking of air evan here on april the first we have to wait wait and see um that's it thank you very very much uh if you would like to know more about this autocompletion functionality please uh please contact us tech at network thank you awesome thanks thanks so um we've now seen three data sets being presented an address registry um to the the cultural heritage data set the marine regions gazetteer we've seen two clients being presented one just taking a copy of the entire uh link data event stream and uh the second client was autocompletion across uh across a fragmentation i've put all the links that you that you need to to recreate that for your own data sets i put them all in the chat so the all the tools that we create as should be at an open belgium event of course are open source and all the data sets are open data so please uh try to get your hands dirty we're i'm an academic so so i'm afraid that sometimes uh what i say is a little bit too early for for for market adoption sometimes but it's i promise you that's pretty close to markets and options so so if you want to be one step ahead start playing with uh with these uh these tools the next presentation is again another data sets use case so now we've mainly talked about base registries or or data sets that really need to be reused as they are the reference for for for many other data sets uh but i think uh olivier also already mentions ah well time series we we should men we should try to to also find an overlap with time series i think that this is exactly what uh mchills from imac is going to uh to hint towards right flip uh you're on mute that's another one for the bingo yeah see if i can pass [Music] iq tests let me know if you see something it is loading so uh i think yes you passed the iq test congruently great floor is yours so yes my name is philippe mchills and yeah i'm i'm working for emac but we're working together on digital twins also with uh with flanders with uh information agency in flanders and um yeah i wanted to explain in this presentation how we see linked data events streams supporting digital twins so for those of you who don't really know what digital twins are they're basically decision support systems for city planners and policy makers that's how we look at them so um it's more than just uh yeah defensive visualizations that you typically see in these demos of course the idea is that we are trying to understand the dynamics of cities by merging data streams and by applying models to those data streams for performing simulations good example is if we want to implement circulation plans in cities then we want to maybe um simulate the effects of several different circulation plans see what the effects are and then choose the ones the one that fits best our criteria the thing with with digital twins and these computational models that are running behind it is that they're quite data-hungry machines what we want to do basically is correlate and process data from from different sources and of different nature so peter was hinting towards it it can be sensor data for a large part of course sensor data is very important for us but also it can also be other data for instance um i will show a case where where demographic data can can play a role as well um and you want to correlate all of this so you will need something else as well so what's the concept of what we are doing in the duvet project which is a european digital twin project the idea there is that we try to see data sources models and visualizations as components that can be fitted generically to a central data block that's that's the concept that we are trying to look at and now of course it's all very nice but if you want to connect these data sources and and they're all in different uh formats and they're all they don't have uh clear semantics or they're not the semantics are not well defined that's uh easily going to bring us into problems it's gonna be an integration nightmare and it's going to be very costly to adapt these data sources to make sure that they work with our models and and what we want to do is to connect any data source with any model so it's a bit difficult then so uh yeah back to the fancy demos the fancy demos of digital twins is what you see it's the iceberg at the top uh but below that is a whole lot of things going on and a big part of that is actually getting data to be interoperable to break the silos that are typically found in these data sources to address the issues of data quality and do things like data analyzation so that's um our biggest problem and we kind of figured that out uh one day we had a very good id and we naively tried to solve the uh issue of figuring out what is the quality of life in a certain part of the city so street by street we wanted to assess the quality of life in the city and we had kind of an equation that would take into account different aspects of the city so this could be are there shops nearby is there public transportation in your neighborhoods how busy is the street you are living in are there parks etc etc so very very diverse data sources and um yeah most of these data sources were available somehow in some form but usually they were not really um yeah semantically well defined so they were not published as openly in data so and we quickly found out that it was way too hard to try and manually hook up every part of every data sets to each other so it was almost impossible and this was really typical for a lot of use cases that we tried to implement using digital twins so um with duets we have the we have the the intent to create a digital twin platform for flanders um so the idea is then okay where is the data in flanders and um there's quite a lot of data um so there's the authentic authentic data sources and we which are being hosted by by the flanders information agency but there's also tons of other data sources spread across so many different organizations they're countless but most of these data sets unfortunately are not published so they're not accessible but even if they are accessible they're not always interoperable so that's the that's the main issue we face um and one by one on boarding just does not scale it's too expensive um so um we were kind of yeah disillusioned you could say uh because um yeah how how do we go about this i mean there's there's lots and lots of data but it's it's really way too hard to just onboard it and use it in digital twins so um we saw earlier today that and this is really giving us hope uh are giving me hope and i was really enthusiastic to see this um that's that it's actually very easy to implement the link data event stream standards and so um i think link data event streams can help in many ways um first of all they can remove obstacles that we are typically facing when we try to publish open data and we have seen that it's very easy to implement and it's also a strategy where we can separate publication from the actual management of the data which i think makes it much more feasible to to achieve the requirements are fairly limited they're well written and they're easy to implement what's also helping is that it's a more robust approach to to building time series around sensor data typically today the approach of keeping time series of on sensor data is to to subscribe to the sensor event stream um but the problem there is that yeah you need to specify what kind of data you want to historically keep and with link data event streams if we just onboard everything as link data event streams not only the sensor data but also the context that we have a robust way of keeping everything the history of everything which is essential in digital twins and make sure that we can time travel not only in the values of the sensors but also in the context of the sensors and also the context of the digital twin itself because if you are doing evidence-based policies and you want to validate the results of a simulation you want to be able to go back in time not only in terms of the results but also in terms of the surrounding conditions if uh if you're doing experiments of uh an implement circulation plan in a city but you don't have this the the situation of the actual streets of that time at the time you were running the simulation then you cannot recreate the experiments and the results are not worth much um so another good thing is that we can have these reusable building blocks where we can do things like reconciliation which is essential and we want to be able to link elements of the of one data stream to elements in another one so being able to have a uniform system of referring to to records and also linking to other sources is essential to us and also of course having the possibility to create derived data streams where we can have where we can subscribe onto the raw data stream apply calibration models do aggregations apply anonymization with all our essential tools for us in building digital tweets and a good example of such a building block is address match which is actually an existing service of the of the flemish government where they based on addresses and and the way they are entered into a system try to resolve that to an actual address record which is very similar to the demo we just we just happened to see for uh when we were looking for vincent trango in all of its possible writings and what we want to achieve basically is to not just have data sources but eventually to have all linked data sources and if all of these data sources can be published as link data event streams then that's going to speed us up considerably so i'm very hopeful and also very thankful for everyone that is doing that thank you thank you very much philippe it's it's one one thing i particularly um liked in your presentation is the fact that you said like ah but it's really important in order even even if you want to prove something later on uh towards your government if you if you got a certain certificate uh saying ah because of uh uh because of that street and and uh and this um uh just thinking and this artwork that is that at that moment was at the museum uh and that's why you get a certificate that you actually visited that that that artwork and that and that street as well just trying to combine different data sets here that then still you also want to rewind your data set or you want to go back in time and make sure that you can still uh still prove that that certificate is correct or or it was correct at that time so that's indeed uh another it's called it's called the data traveling capabilities uh traveling uh data time traveling capabilities i'm sorry um and and it's considered essential in also in big data processing by the way so yeah and certainly if you have digital twins where you have then forecasting models and then based on 100 data sets then you do a certain forecasting then if later someone comes to you and say ah but why did you do that in hindsight look look what happened we could have predicted this then you can say ah could we okay let's let's go back and let's uh that's also that's also the nice uh very nice aspect on elders i think because it includes archiving um or archiving specifications so you can be specific about what your intent is in terms of retention of data in that kind of stuff it's really important yeah okay great so let's move to the last presentation and then there's some room for uh questions uh i hope it's a uh analysis are you are you with us we had some technical difficulties at the uh in the beginning i hope we will we were able to resolve this by now i hope um hi i'm alright we can hear you that's already a good thing yeah i had some difficulties but that's solved right now um i should be able to share my camera and share my screen so no webcam for me but i'm on the laptop of my daughter so i think we blocked that earlier try to cheer my screen otherwise peter maybe you can share your screen and we can switch to that then yes um i'll give it one more try now i of course need to be able to open a powerpoint presentation called um yeah i'm on a computer that's not my problem actually if you want i can show the presentation uh okay yes that would hurt that would help me yes okay okay i also have it ready astrid do you want me to do it instead okay i'll just uh just try to do it uh it was it was loading it said ah okay i think i now share my screen yeah yeah okay okay perfect yeah thank you so i will just uh shout when we switch uh perfect yes thank you so much for this collaboration uh so thank you peter and all the colleagues uh to have us here and as um informative london and now digital uh digital flandering so maybe digital flanders is the new name um what i really want to share with you today is the experience we the experiences we had and the capacity capacity building we did at digital vlandryn so i won't go into technical details but i'll give you a short uh tour around in our learning curve about the linked data event streams and then you will also see the link with the digital twin project and um the items philip already mentioned in his uh in his slide so you can move on to the next slide please yes so maybe um i just wanted to um to post this because digital of london is just uh the new name um very recently of uh information agency for the international community so it's actually the same uh company with some more i.t uh departments now involved and it's now called the guitar plan but we're actually the same people um okay next thank you so within the digital of london we have um different programs and who are um working on the the digitization of the flemish government and its stakeholders uh and within the heat of london we also have a program where i'm working for and that's the program authoritative data sources of detail of land and uh within this program we have uh some experiences about linked data event streams and insights and that's what i really would like to share with you today so we have one aspect on the smart data trick and then link data event streams for the building registry and the address registry um a really short thing about oslo and the linked data event streams for the large scale reference database also called hereby or basisguard flandren for the dutch speaking people so first of all i want to zoom out a little bit um from open data to smart open data so um we started a track i think one year and a half ago um about smart data and to zoom a little bit out on how we can uh open up our scope and um with an open mind and open innovative thoughts how we can manage all the data and the data streams that are coming ahead of us so we have now uh certainly in the smart city landscape but also in governments and the evidence-based policy track everybody's going into that data becomes still more and more a foundation for designing the society and the future of the citizens and and policy makers of tomorrow that's also the link to what philip just told and we have multiple data sources we have the slow moving data as we know it and that's the data from the like for example the base registries and the authoritative data sources and we also have more new data streams like the fast moving data from sensors or real-time updates we need from different data sources and those uh those things are very challenging those huge amounts of data how can we cross those data on the different domains how can we link all those data with their context how can we make data more reusable in that context and how do we deal with scalability and once only principle and all that kind of um challenges can you skip yes so that's why we what we call them the smart data trajectory and we really want to focus on the findability accessibility interoperability reusability and the ease of use of data and for that um linked data is for us key so what we understand in smart data is actually that it can make the connections between the different data sets and if you then consider a smart region a smart city or something like that you need to be able to connect the objects in the field like a road a building an address with potential fast-moving data sources like sensors and the smoother the link is going the more information you can distract from it and this can help or enable to provide solutions in the field of mobility healthcare environment so that's the zoom out i wanted to make and to have all this the qualitative data alternative data sources are really fundamental to have it on to have these data available to link all this to okay and so in our learning curve step one is um we started last summer a prototyping phase on linked data event streams and linked data fragments um and then you can yes and to make the story complete it was together with the team of imac id lab but also some enthusiastic students from open summer of code and of course our information flanders information agency or informative land we started a prototype uh on linked data event streams and if you now click uh a street thank you all right it's uh i'm i'm showing it yeah but uh but i also wanted to make make uh make clear to the to the the community at open knowledge belgium that we also did it at open summer of code so so uh so we also so so the foundations of link data event streams really also come from within within open knowledge belgium itself okay so um prototyping with link data event streams for fast and slow moving data so what the the the first hurt we hurdle we wanted to take was of course um how can we uh manage uh sensor data so fast moving data and um are we able to to publish it in a in a sustainable way and what's the the knowledge we need for that um and how do we relate it with the slow moving data sets and so there was um a kind of capacity capacity building needed um and then we started with with the prototype with the team of peter on link data event streams it also gave us um some really interesting insights on the architectural part um you will see it later on in the presentation it really is the blueprint for something big we're doing today and it also gives a really valuable insights on scalability load the possibilities on the query side so for reusers etc um next slide so what we um at least what i uh found really uh valuable and and learned from the prototype was that we could publish um a fast-moving data set and a slow-moving data set so sensor data on which we were very um or yeah quite immature and also our base registry the address registry as link data event stream so and it was quite a similar way we didn't have to do anything exotic it could fit for both types of data sets and um some really interesting insights on the linked data fragments where you can have your query module and um question it question efficiently uh through different data sources that was really um uh interesting for me and then the second um step um was actually uh the opportunity we had to um step into the samick projects with uh peter his team um to make um a few of our authoritative data sources into linked data event streams and you can see them already up front in the above so we have the building registry address registry large scale reference database and it's all based of course on the semantic interoperability model of oslo so it's really a quick overview um for the building registry and address registry we already work with event streams but um in this um semi pilot uh we move oh okay thank you linked data event streams so um the ongoing work right now uh i'm not going to step into detail is that actually uh the link data event stream is uh it's ready to be published and it's now in a test phase uh as a projection on top of the raw uh data set what's that what is the link pointing to ah well that was ah that should be an error the that's that's not a link uh yeah it's the yeah okay it's the flemish uri standards okay but i will put a link to the to the pull request that white prepared yeah in the chat maybe a copy paste stuff okay and key in this um in this realization of link data event streams is for us um with our colleagues of uh oslo open standards for linked organizations is the semantic uh interoperability model and so the vocabularies and the application profiles and i the url is also on the on the web page uh it's key to achieve a link data event stream uh for our data sources and you can switch to the next one and the standards being used for the realization of this one are addressing register and i'm sorry for that but it's in in dutch and herbau in register so um also available on that of london.be move to the next pizzer okay and then we have the large scale reference database also called uh here b or basisguard flandren which is a large-scale topographic map containing um lots of information about uh buildings parcels roads uh whatsoever and uh today uh this is available as a vfs and is also um dumpable as a by download downloading your data set and there uh our colleague is still working on and then you can move to the next slide this is um in the face where um we need to run now an oslo standardization project to make it fit and then we can move on with link data event stream implementation so that's quite brief about this one and then um step three it's um even um it's always a little bit bigger um and step three is actually that the link data event streams and the concept about it is really at the core of our new architecture that we are now going to um further uh uh how do you say it proposed to the policy makers in uh belgium in our relative project so roland is it's a really big thing in in flanders and um so we are now preparing um how do you call it an english a nota for the flemish government in which we present our architecture uh and all our um tools telling all our goals for this reliance project um and really in the core of this we also use link data event streams in our technical solution so this is actually a zoom out of the release project we are now working on sensor data platform and what you see here is actually um four silos or four um key components of this uh trajectory um and why are we doing this that's maybe the first question to answer uh analysts you're muted all of a sudden can you unmute ah and uh she's gone yes no i'm like okay great it was done automatically but uh as i was saying because i'm really enthusiastic about the uh project and the sensor data platform we are going to uh page there is that um we really want to uh enable data publishing and data reuse uh for a more um and brighter and bigger uh data flow of all kinds of data and specifically sensor data and what we do so we re what we try to do is uh bridging um the gap for the data suppliers and the data sources and also sensor data sources to unlock them from there maybe silo they are in and uh by all by um moving it into the architecture we are proposing here with open source building blocks we want to enable this data to flow and to be uh much more easier to reuse by uh other partners by new business models that kind of thing so the lancer block you see in the middle consists of all kinds of open source components we sometimes also call it a publication street of components with in the core link data event streams with which all those data suppliers can more easily maybe publish as linked data their data and unlock it from or the domain or the supplier or the location where they uh originated from and that's the first part and then um but that's maybe not this relevant here in this um meeting we really focus on standards for all this um we want to have an ecosystem that works with it and a governance on it and so this is just um an image of our functional architecture in a more detailed way but what i really wanted to show you was that link data event streams is really in the core of our solution it is a draft but um i think it's a beautiful way forward to unlock the data thank you thank you very much uh annalise um i would like to ask all speakers that that that have spoken to to share their webcam again with uh so that so that we can be visible again to the to the audience and um yeah well i i think the the really nice thing about about your presentation analysis is is that is to to show that that this was really the the beginning of linkedin event streams in in last summer uh during during summer of code but that had evolved and that we got more and more people on board uh while doing that and that now it's really at the core of of what we want to do uh regarding data management at the the the flemish government um which of course will will translate into into multiple tools generic tooling that that that will be uh created but uh not to be underestimated is that you also said that there are going to be two link data event streams that we're going to start with one the address registry in flanders and to do the the here be in front of flanders the grb the reference which is the which is exactly the bgt in the netherlands and the address registry or the address and building registry in the netherlands is also going to be to do and also the address registry in flanders so this will cater for some really interesting cross across member state use cases um and and i'm really looking forward to to seeing how like two completely different backends with the same data but with different slightly different data models because the netherlands has their own data models and and flanders have their own data models that we can can still then later on align them and make sure that we can seamingless uh seamlessly uh uh query over the the two data sets in parallel at least that if we can give a demo like that that would be great and if then at the same time we can for free give a demo where we can also query over marine regions gazetteer over the the five collections in from the museum in ghent over uh digital twin models over uh uh what else did we talk about i i almost already forgot um but um all these different data sets i think they will they will become queriable to the masses this way and we will have an automatic ecosystem when when people set up a new intermediate index it will be added to the ecosystem if they put it put it put it down it will also okay they disappeared but still the the ecosystem will be able to recover by just uh fetching android data just in time we have about two minutes left for uh questions luckily i don't see too many questions popping up in the chat but if there would be any questions it is no or never and i will only take one question which was not according to us to plan but still i think we had an interesting session any questions in the chat three two one ah i see shirts typing shorts feel free to immediately uh take the take the floor ah thanks peter yeah i have one question um uh how do you publish your data set information if you use linked data event streams for instance how does this ld s fit into the d-cad model uh aravind told something about slash feed for publishing your event streams but how can we discover your event streams uh yes this is also part of the of the 3cg specifications so you can also just go to the specification and read about dcat compatibility where that's mentioned but indeed i i do see that that these collections are going to be added as distributions of data sets so uh that the the dcat model is is a is a catalog uh the data sets and distribution i think the data set is like the address registry and then the the defeat is your specific distribution of how to retrieve the uh the data set but but also adding the the metadata about the specific collection and the views that are created on on top of that you will be able to have even richer uh metadata in which you can use your dcat catalog to say like oh i just want all the uh collections or all the distributions that for example have a use the property social result time and for me social result time that would indicate that i have a time series so can you can uh can can use that in the tree specification just as uh geraldine also posted in the in in the chat we also indeed uh uh points to dc terms conforms to to indicate that you uh confirm that you conform to the the three specifications so that in that way you can also immediately find all the data sets that that use this way of publishing their data okay thank you good and this was immediately a question for me so so so thank you very much it's six o'clock my uh my kids is screaming downstairs for for my attention so i will also not take more of your uh time this way but uh i want to wrap up by saying that the presentations uh please dear speakers send them to me if i don't already have them i will make sure that they're uh posted online so that it can be used by uh the uh by the audience to uh to to to read up on it and to click the links in in in your uh presentations um the video itself will also be shared on the open belgium uh website if you uh in the audience want to uh start get your hands dirty with link data event streams ping me or go to the github repository or send us send us an email or just immediately go to the specs get your hands dirty we will be more than happy to to help you out if you bump uh against uh against anything and last but not least i would like to um but not made penultimate uh uh but not but not least i will thank my speakers brett brits analyst philippe olivier erwin voter who already left and ensures thank you very much for being part of this uh thanks for for making uh making link data event streams credible because because thanks to your implementations and thanks to your uh projects using it in the real world it is becoming a reality not because there's some vague specification uh about it um so thank you very much and for your enthusiastic uh presentations and last but not least i would like to thank of course the people from cloud86 who have been uh great at providing us with uh support uh when when things didn't always technically work out so with these final words um thank you everyone and uh see you uh see you online in in your next question about leak data event strips bye okay okay you