Reboot of “Using interface encapsulation to listen to linked data predicates”


3 Years ago I wrote a blog post which was a submission to the ISWC 2014 Developers workshop. The idea has been implemented with the Enyo framework which at the time was still a viable ecosystem. The implementation has been used in production in various installations of our systems.
Time has passed on and the EnyoJS framework is no longer supported, its successor was very much tied to react so would be very framework specific. In order to come up with a simple solution to the encapsulation problem I decided to reimplement the whole idea using WebComponents

Design Principle

One of the major issues with using linked data nowadays is that people still conceive the whole tool chain rather complex, even though JSON-LD has dramatically improved the usability of Linked Data in various front-end application frameworks. The central problem described in my previous post still remains, there is no semantics on UI level, front-end frameworks are able to consume JSON-LD but only by ignoring the semantics and treating it just like any other data stream. On the other side of the spectrum are UI building tools who manifest themselves as classic Monoliths, “So you want a front-end framework, you’ll need to use our triple store as well” This whole position is even stranger if you come to realize that in the Linked Data world everything can be done according open standards.

RDF, SPARQL, SPARQL-Protocol, LDP and more recently SHACL are all open standards who brilliantly inter-operate with each other and provide the building blocks to just develop components to create applications.

In this article I’ll describe the ideas behind our new set of WebComponents which allow you to absorb linked data in your application front-end without installing a monolith

The end goal

With the introduction of WebComponents came a new way of extending HTML applications and extending the semantics while still being able to use any traditional UI toolkit. The second major element is the SHACL standard, now there is a standard to describe which elements  ( triples ) you want to select and use for your application. Inspired by SHACL and web components I came up with the following desired structure

<node-shape target-class='foaf:Person'>
    <property-shape path='foaf:name'></property-shape>
    <property-shape path='foaf:img' bind-to='img[src]><img></img></property-shape>
    <property-shape path='foaf:knows'>
        <property-shape path='foaf:name' bind-to='.name'>
           <span class='name'></span>

As you can see we map SHACL terminology within a relative standard HTML layout, this allows you to do any standard markup and styling through CSS. It will not interfere with any other standards DOM interactions on the elements encapsulated within the WebComponents.

To load the Linked Data into a <node-shape> we use rdf-ext a set of javascript libraries which again is adhering to a open standard. The <node-shape> and <property-shapes> will coordinate the propagation of the data through the HTML automatically, even dereferencing is taken care of. When multiple values are found, the encapsulated component is automatically repeated.


Although we use SHACL as guidance there is no validation in place yet, we only use the selection process of SHACL to select these parts of our Graph that we want to display in our front-end. This also means that we might display incomplete Graphs, that is a issue we need to work on.


This whole idea is work in progress, the current implementation based on WebComponents is now being tested with a POC and the results look great! We are planning on publishing the components as opensource on our github repository.

Some more detailed articles on how this works internally will be published as well!

Central Version reporting of deployed artifacts with JEE

While building our RESC.Info solution stack we found ourselves with the challenge to query the build versions of the components installed. After searching the web and consulting various communities we found out there is no ‘standard’ way of solving this.

What we actually wanted is a way to query the installed version of the various modules we deployed to the Java Container without any predefine knowledge which modules are actually installed. We did not want to rely on any platform/container specific solution to solve this.

The approach taken

Java comes standard with JMX, Java Management Extension, it would be preferable to utilize such a infrastructure instead of coming up with our own.
So we decided the technical approach to take would be JMX, now we need to define what we wanted to expose, we decided to stay very close our original goal, extract version information from the installed artifacts programmatically.

We identified 4 main attributes:

  • Name
  • Full name
  • Artifact
  • Version

Since we use Maven for our build process ideally this information would come from the build process itself, there are tons of references on the web on how to do this. We decided to use the Maven resource filtering to generate a properties files, in our pom.xml we have:


in src/main/resources we placed a file which looks like:


During the maven build process the variables are replaced by the actual data from the POM file which we then can reference from the version reporting code.

Drop in version reporting

On of the other requirements was to have ‘drop-in’ version reporting module. You don’t want to code version reporting over and over again since we would have the version in the same place all the time anyway. So we created a Maven artifact we can simply add as a dependency to our project. This leaves only the task create and modify some files in our project and from that moment on everything goes automatically.

Exposing the information

To expose information to JMX the easiest approach is to expose a MBean to the containers MBeanServer. This is a two step approach

  1. create a interface which name ends with MBean.
  2. create the actual implementation of the interface.

Since we are actually interested in some metadata of our artifact we will call our interface MetaDataMBean

package com.example;

 * Interface for Metadata exposure
public interface MetaDataMBean {
    public String getVersion();

    public String getName();

    public String getFullName();

    public String getArtifact(););

Next we will do the implementation of our MetaData class

package com.example;

import java.util.MissingResourceException;
import java.util.ResourceBundle;

public class MetaData implements MetaDataMBean {
    public String getVersion() {
        try {
            return ResourceBundle.getBundle("version").getString("version");
        } catch (MissingResourceException e) {
            // the file is not present
            return null;

    public String getName() {
        try {
            return ResourceBundle.getBundle("version").getString("name");
        } catch (MissingResourceException e) {
            // the file is not present
            return null;

    public String getFullName() {
        try {
            return ResourceBundle.getBundle("version").getString("fullname");
        } catch (MissingResourceException e) {
            // the file is not present
            return null;

    public String getArtifact() {
        try {
            return ResourceBundle.getBundle("version").getString("artifact");
        } catch (MissingResourceException e) {
            // the file is not present
            return null;

As you can see not to much rocket science here, we simple return the strings we get from our file which is created during our build process.

Hooking up to JMX

In the web.xml of your application you can define a <listner> tag which will be called as soon as the application is deployed. the <listner> tag requires the name of a class within your war which subclasses javax.servlet.ServletContextListener. When your war is deployed the contextInitialized override you need to define gets called, this is the ideal location to do one time initializations like the version reporting.
We create a Class, LifeCycleListner which extends ServletContextListner, on initilization we create the MBean, and register it with the containers MBeanServer. When the context is destroyed we will deregister it.
As registration name and type we use the full package name and choose a type identifier. This identifier is the actual key by which later you can retrieve the version information of multiple artifacts with a JMX query. In our example we chose for the type name ‘EXVersion’ which is a arbitrary name, but it needs to be the same for all your projects !

The context listner looks like this:

package com.example;

import java.util.MissingResourceException;
import java.util.ResourceBundle;

import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

public class LifeCycleListner implements ServletContextListener {
    private MetaData metaData;
    private ObjectName beanName;

    public void contextDestroyed(ServletContextEvent arg0) {
        MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();
        try {
        } catch (MBeanRegistrationException | InstanceNotFoundException e) {

    public void contextInitialized(ServletContextEvent arg0) {
        MBeanServer mbs = ManagementFactory.getPlatformMBeanServer();

        try {
            this.beanName = new ObjectName(ResourceBundle.getBundle("version")
                    .getString("artifact") + ":type=EXVersion");
            this.metaData = new MetaData();
            mbs.registerMBean(this.metaData, this.beanName);
        } catch (MalformedObjectNameException | InstanceAlreadyExistsException
                | MBeanRegistrationException | NotCompliantMBeanException e) {
            // TODO Auto-generated catch block
        } catch (MissingResourceException e) {
            // the file is not present
            System.out.println(" is not present!!");

In the context initialized we already use the file to get the artifact name. This is also a direct test to see if the file is present at all, if not we don’t even bother registering the MBean.
We save the MBean name to destroy it when the application gets undeployed.

To have this code called on application deployment we need to register a listner in web.xml:


Packing it up

If you create a standard Maven project which you deploy to your local repo with the above files included you can use it as a dependency on your other projects.

In your project you need to do 3 things.

  1. add the template in src/main/resources ( sample above )
  2. add the extra lines to the POM.XML ( sample above )
  3. add extra lines to web.xml ( sample above )

Querying the information

So now we get to what it was all about, how do we extract the version information without any predefined knowledge of what is installed ? We use the simple JMX api to query for our EXVersion type, a code snippet looks like this:

MBeanServer thisServer = ManagementFactory.getPlatformMBeanServer();
        try {

            ObjectName query = new ObjectName("*:type=EXVersion");

            for (ObjectName name : thisServer.queryNames(query, null)) {
                out.println("module: " + thisServer.getAttribute(name, "Name")
                        + "tName: "
                        + thisServer.getAttribute(name, "FullName")
                        + "tVersion: "
                        + thisServer.getAttribute(name, "Version"));
        } catch (Exception e) {

This will print out a set of lines with information about ALL the deployed artifacts which expose the EXVersion type bean.

Rounding up

This is very simple approach of creating a centralized version reporting method without to much infrastructure. It is easy enough to simply include in all your projects with a minimum amount of configuration. It does have some limitations, e.g. 2 deployments of the same artifact on different contexts will not work.

For our internal use we did extend the MetaData class to have some extra properties, but those were very specific to our project.

Using interface encapsulation to listen to linked data predicates


The article was a submission to ISWC 2014 Developer Workshop

Linked data and its RDF model is known for its flexible schema less structure and integrated meta-data. Although this is great for expressiveness of the data, its is a nightmare for interface developers since all the modern interface paradigms are tree based.

The standard way of interacting with data in these user interfaces is to use application logic to interact with interface elements which needs to query the data and decide which piece of information to put in which element. Trying to push free format RDF in a tree is not a easy tasks and often results in very static interface for a specific graph structure.
Wouldn’t it be more intuitive to use the meta data in the RDF to decide which user interface element treats which property? And even more intuitive let the UI be able to decide to get more data from other linked resources without needing specific application logic ?

Traditional Model

Lets try to go through the traditional model with static data:

 Bart, van leeuwen, @semanticfire,
 Select firstname, lastname,handle,companyprofile from data
 Field firstname
 Field lastName
 Field handle
 Field companyProfile

If any changes are made on the interface, it is up to the application logic to extract it from the interface and modify the underlying data model.
So if we get a new data structure as input we need to change both logic and interface to react to that. When we want to react to different types of input structures both the interface and logic are getting more and more complex. This is mainly due to the fact that the data is pretty ‘dumb’ we need the logic to identify various pieces of data and match them to user interface elements, the other way around is even more complex. Getting the modified data an sending it back to the underlying data model. There we need a extra step to make sure both UI and application logic are in sync with the constraints of the data store.
The traditional solution while dealing with RDF data is to use SPARQL queries to get somewhat structured data which resembles the result of the SQL query above. Although we can use traditional methods to show the data, we loose a significant part of the semantics around it, the data is ‘dumb’ again. Updating data is even more complex since SPARQL results might come from multiple endpoints and that information is not present in the SPARQL result set.

A different approach

Now how can we use the context in RDF to eliminate application logic and put all the logic in the interface. If we are able to do this it would allow us to simply be ready when the piece of information we are able to show comes by and complies to the constraints we have set on it.
During the development of some of the front ends of our system we started out with the traditional SPARQL way. One of the important reasons to use linked data in our solution is the agile nature, adding extra properties or replacing them is easy and doesn’t require large schema updates. However on the front end we were still struggling with multiple SPARQL queries for the various incarnations of our data. This should be done in a smarter way.

Introducing EnyoJS

In our search for toolkits to create mobile applications we came across EnyoJS [1] a Javascript framework which originated on the Palm Pre smart phones as a part of WebOS and evolved in a Framework for platform independent applications. The current Enyo 2.4 version is the basis for LG’s latest SmartTV Platform. The concept of EnyoJS is encapsulation, components should have no knowledge about their place in the hierarchy, they communicate with bubbling up and water-falling down events. They have no control who receives these notifications and events. There is also no limitation on which components encapsulate each other. The flow of events and notifications is left undisturbed by encapsulation, adding a extra component around another doesn’t break the chain, unless the inserted component deliberately listens and ends the event chain. Components can directly talk to elements they define but should not talk to the inner components of those elements. Neither should they directly talk to their parent components.

The EnyoJS way

The encapsulation gave us the inspiration to see if we could use this method to add a linked data property to components. By encapsulating a standard UI component with a linked data aware component we would be able to define at interface level which element should contain values of predicates.
So if we would have a UI Container C which contains a Textbox T traditionally it would look like

C1 → T

The container would use the traditional SPARQL way to get data and update the value v of T . Our approach would be that in between C and T we place a property component P which is configured to react to predicate “example:foo” and propagate the value of “example:foo” to its components.

C2 → P → T

and instead of the traditional SPARQL way we simply let C announce to its children it has a graph available, P will pick up any triple which has the “?s example:foo ?o” pattern and extracts the value ?o and propagates this to its underlying components. P will stop the waterfall. This method would still allow to insert a extra component in between, e.g. a Box B

C2_2 → P → B → T

Since B is does not have a “setvalue” called by P we will simply call T directly, remember we can call methods of defined components directly.

If the value of ?o is a URI, P will try to load that resource and announce to its components that it has a Graph. So if I would like to know “foaf:name” from someone I “foaf:knows” it would look a bit like this.

C3 → P¹ → P² → T

Where P¹ listens to “foaf:knows” which will load the graph and announces it to its components where P² which then will set the value of T to “foaf:name”
Presenting multiple properties is no problem either if I am also interested in the “foaf:mbox” value of my “foaf:knows” relations ships this would work as well.

C4 → P¹ → [ P² → T¹, P³ → T² ]

Here P³ represents “foaf:mbox”
The above example snippets can be found in the github repo [2] from the samples you can clearly see that the ‘meta-data’ stays close to the interface level and we only fetch and announce the source graph once. The snippets just give a rough overview of what is possible with this approach.

Additional possibilities

The EnyoJS platform knows the concept of repeaters, which allows components to contain a virtually unlimited amount of instance of another component. This would solve a cardinality issue.

C → P¹ → R → P² → T

Here Repeater R is used to create multiple T components from all the “foaf:knows” relations I have.

Its also possible to combine multiple components inside a repeaters, e.g. P³ listens to foaf:mbox

C → P¹ → R → [ P² → T¹ , P³ → T² ]

this would result in a list of names and emails addresses of all the “foaf:knows” relationships in my profile.
The way back.
By maintaining the ?s on the P components propagating updates back is relatively easy

C ← P ← T

if we update T, and configure P to listen to the updates ?u to value ?o while maintaining ?s related to P we can simply construct a triple out of that

 ?s → P:predicate → ?u

which replaces

?s → P:predicate → ?o

We now would be able to either construct a SPARQL Update, provided we know which endpoint to use, or use LDP spec to to do a patch on ?s
Of course you might want to constraint the actual execution of water-falling based on property values, e.g. only show properties which are no older then one week. And only show a certain component if there actually is data, or have property component just be responsible for containing other properties without generating any UI. It even allows to listen to the same property with different constraints.

C → P(ex:foo >= 50 ) → Tgreen
C → P(ex:foo <50 ) → TRed

If T would be a editable field passing the threshold of 50 would in the end propagate the update up to C which would then announce a updated graph, which in turns would show the T with the right color.
For formating back and forth EnyoJS provides all sorts of transition hooks which would allow to format a xsd:DateTime to something human readable, and back to xsd:DateTime after modification


By using the encapsulation mechanism in EnyoJS we are able to to combine both UI description and the related RDF properties in a single place without being bothered by external code to sync the model and the interface. Although surely in its infancy the approach described here is not only a nice idea, it is practically being used in our applications.

The code is not in the public domain yet, but this is certainly something we will be doing in the near future.


The sample snippets are made available on Github [2]. Handling RDF data is done with rdflib.js [3]
This is none working code right now, I’ll assemble working samples before the conference
Current state and usage
By the time of writing the technique described in this paper is used deployed actively on several monitors at fire stations in the Netherlands

Future work

One of the more obvious additions would be language support., set a preferred language on literals so you can react to multi language RDF.
Multiple property update predicate relation, as in the example above with Tgreen and Tred, maybe a P which updates and listens to the change of ?o but also modifies another property on T, the color in this case.
Using Json-LD to define properties, this would allow the omission of full URI’s and use a context to solve them
User property definitions and constraints based on the work off the future Shape expressions Working group [4] or the Resource Shapes 2.0 submission [5]



Using IBM DB2 NoSQL Graph Store in Websphere Application Server Community Edition

This is the first of a series of blog posts about our experience with the IBM DB2 Express-C NoSQL Graph Store (hereafter DB2 RDF) in combination with IBM WebSphere Application Server Community Edition (hereafter WASCE).

The DB2 RDF product allows the storage and manipulation of RDF data. The data can be stored in graphs, all according to W3C Recommendations. The DB2 RDF product uses the Apache Jena programming model to interact with the underlying store. In the very detailed documentation there is an outline of products and tools needed to get the basic DB2 RDF programming environment going.

This series of articles is specifically about using the tools inside the WASCE environment. While developing our RESC.Info product we gathered a lot of experience which we like to share with the community using this article. We will also be presenting our experience during this years IBM Information On Demand 2013 in Las Vegas.

The series will cover the following topics:

  • Configuring WASCE data sources
  • Assembling the correct Jena distribution
  • Dealing with transactions

This first article is about configuring WASCE data sources for use with the DB2 RDF and Jena programming model. This is NOT meant to be an extensive installation guide for these products, you should refer to the respective product documentation for more information on installation.
It is very important to select the correct versions of the various products:

  • IBM DB2 Express-C 10.1.2
  • IBM WebSphere Application Server Community Edition 3.0.4

Creating a DB2 database and graph store

To  be able to use the DB2 RDF features we need to create a standard database with some specific parameters. The DB2 documentation contains extensive information for this task. To create a database ‘STORE’ that supports DB2 RDF we issue the following commands:


For the correct administration we also need to execute:


Now that the database is created we still need to create a graph store inside the database. This is done with the following command:

createrdfstore rdfStore  -db STORE -user db2admin -password XXX -schema public 

This can take a while. After completion you will have a graph store ‘rdfStore’ inside your database ‘STORE’. To check the presence of this store issue the following command when connected to ‘STORE’:


The resulting table should contain reference to our store ‘rdfStore’ in schema ‘public’

WebSphere Application Server Community Edition installation

Install WASCE with the installer, but do not start it yet. WASCE is distributed with some older DB2 JDBC drivers which interfere with the DB2 JDBC4 drivers that are needed for the DB2 RDF interface. In the repository directory of WASCE look for the path


and delete the db2 sub-directory. Run WASCE with the -clean parameter, which causes WASCE to cleanup all references to the included DB2 JDBC drivers.

geronimo.[sh/bat] run -clean

Installing db2jcc4.jar

Now it is time to install the JDBC4 driver into WASCE repository. In the advanced mode of the console you will find the Resources/Repository tab where you can add new jars to the repository. Select the db2jcc4.jar from your <DB2_INST>/java directory and fill out the fields as shown in the image and click ‘Install’.

Creating a Database Pool

Once the correct jar is installed the creation of the connection to the database is the same as any other regular database connection. Select DB2 XA as ‘Database type’ and fill out the connection information. You should only see one JDBC driver here, the one we just installed. Fill out the details of your regular DB2 database ‘STORE’ and click ‘Deploy’.

After a database source object is created we can use it in the simple SQL entry field, select the newly created data source and issue the following command:


The result should be the same as the result we had after issuing this query from the command line.


Now we have setup a DB2 RDF connection inside WASCE with the correct version of both products and connecting drivers. The next step will be to create a simple Jena based application to interact with the store.

Simple Application of Linked Data Principles for Firefighters

One way firefighters world wide assist themselves while navigating through towns and cities is recording ‘distinctive points’ (actually that is how we navigate through smoke as well.) So instead of a ‘turn left at the third traffic light’ we often record ‘turn left at ABC Pharmacy’. So where does linked data come into play?

In the current economic situation shops come and go, so ‘ABC Pharmacy’ from the example might be long gone, leaving a driver clueless as where to turn left!
What stays the same is the address, but then again navigating on addresses is not really trustworthy so how can we use this address to generate a distinctive point?

In The Netherlands we have a public data set called ‘Building and Address Base Administration’ this is a official nation wide register of all buildings, dwellings and addresses throughout the country. One of the interesting features is that this data is internally interlinked, and uses nation wide unique identifiers. A absolute ideal situation to generate linked data from. If you inspect the dataset more closely you will actually find out that a address and a building are loosely coupled, that means if for some reason a full restructure of addresses takes place, the building identifiers stay the same.
Back to our problem, we want to know the business located in a specific building so we can use it to navigate. For this we use a semi official open chamber of commerce dataset which uses the building identifiers as location specifiers. This means that for generating the distinctive points, we only need to locate a building based on its address and then query the chamber of commerce data to see what business is located there!

So no matter what business is located in the building, as long as the building doesn’t move we can automatically find the businesses in that building and generate up to date distinctive points with linked data!

The 99% of the time that public infrastructure does work

When I explain people about what I’m working on, better information for first responders, the conversation quite often drifts into the direction of infrastructure resilience. Telling that I intend to use open data sources, externally hosted API’s, public 3G and internet backbones amazes people. The amount of what-if scenario’s explained to me are endless. And yes, these concerns are very valid. If for example an airplane would crash in the middle of my service area there is more than a fair chance that all public communication networks will be overloaded. But how big is the chance of that actually happening? So I’ll be fair about the fact that there are a few days in the city of Amsterdam where at least mobile communication systems suffer. These are the few hours around new year celebration and 30th of April on Queens-day. So two days a year there is a chance that the system I propose might not work.

Now let me ask you the following five questions:

  • Is all of the above a good reason to not try and use public infrastructure?
  • Are these two the only days that our first responders are in real danger due to the lack of information? Or does that threat exist during every incident?
  • Is it therefor fair to deprive them from free, valid, and usable information 363 days a year just because the other two days the system MIGHT not work?
  • Specific to the Dutch situation: did recent history tell us that a private infrastructure is as resilient as it claims to be?
  • Is it viable to build a proprietary complex system to base all our digital communication upon hindering innovation and agile development and spending serious amounts of public money?

My guess is that you can tick of 5 ‘No’ s for the above questions
But current practice is that we have specific information systems for large scale crisis situations, or incidents at very specific sites. None of them are used on a regular basis by most fire fighters, and when needed they often do not contain the guidance and information which the actual situation requires, the black swan! The end result is that first responders are not common to use such systems, and when needed they overlook them completely because it’s not in their standard action pattern.

The reality I face in my regular everyday shift in the city centre of Amsterdam is that more information is publicly available then we actually can think of as a fire department. Several times this has led to situations that, on hind sight, could be tackled differently, but we simply did not had the means to query the additional information. During these relative small scale incidents I would argue that we have put our colleagues at a bigger risk then strictly necessary, but only if we would have had the means to address the incident differently. The main thing about these incidents is that none of them made large scale news, no excessive amount of tweets, no overload on cell phone networks etc. A system based on standard available infrastructure would have worked without problems in these ‘standard’ situations.
So just because we can’t guarantee these systems to work in exceptional situations, we do not deploy them at all!

Why not build up automated deployment plans and information resources based on open data sources using standard wide spread technology which is cheap to deploy. First responders will start to learn and leverage the benefits of systems like this and embed it in their standard action patterns. This will result in a better adoption of modern technologies in our day to day operations as well as in large scale crisis. Being confronted with new and previously unknown information will enlarge the insight in the complexity of some simple but potentially dangerous situations. And yes there is always a risk that in a certain very specific situation the whole, or part of the, infrastructure might not work. The fact that first responders know about the potentially available sources of information might actually influence their own resilience just by thinking about potential hazards which these systems might have shown. Even in the case the systems are not available.

First responders are no robots who will be commanded and controlled by smart devices. They are autonomously thinking beings, which in an agile nature deploy skills and tools available at the time when they need it. When smart information systems are not available they will come up with other tools and skills to do their work safely. But please don’t take away the enormous wealth of information in 99% of my alarms, just because it might not work on the 1% of extreme conditions I might ever face!

The confusing shared visual representation

You just finished a novel from your favorite author, while reading you have build a visual image of the scenery described by the author. A bit later the filming by a well known Hollywood director makes it to a cinema nearby. A big fan as you are, you’ll be surely going out to see this movie! But after the opening scene you will find yourself confused and disappointed, the depiction created by the director doesn’t match yours at all.

You wake up in the middle of the night during a holiday in a hotel, you have no idea where you are and it takes a few seconds to realize the environment you are in is the hotel you checked in the day before.

This phenomenon is perfectly described in a recent article ( , and there is even a good explanation in it !

In the Fire Captain training in the Netherlands you are taught not to compose an image based on the verbal information you receive from the dispatch unit over the radio. Even the on site explanation by an informant should be listened to carefully. The reason for doing this is to prevent the same confusion as described in the first two paragraphs. Composing an image based on information you haven’t yet confirmed yourself creates a great risk. Being a Fire Fighter you want to march into action, the decisions you make are not the best, but the most acceptable for that moment in time. If you construct a plan based on an image you didn’t confirm you might find yourself confused.

Recent developments in the information management field for first responders are more and more facilitating the composition of shared visual representation. The idea behind this concept is that we create a common user interface with a visual representation where all the information that is available is displayed. We have some very large concerns with that approach:

  1. The assumption is made that every single player understands the way the information is presented. GIS based applications are generally used for these visualizations, that is fine for people who work with building plans in their daily life, but volunteer fire fighters may only be confronted with this type of visualization while working for the fire department. It adds to the confusion
  2. Not all the first responders have the time to interpret and analyze all the data shown on the interface, select what they need for their job, and realize that the actual situation might be different from what they concluded from the shared visual representation ( see paragraph 1)
  3. The detail that can be shown on this interfaces is really high, but that creates a expectation. Experience in Amsterdam has shown that the satellite navigation system sometimes shows the wrong location for a certain address, it happened more then once that the unit rushing to the scene focused completely on the navigation system and passed the actual address.
  4. With the detail level of the interfaces comes another issue, the data you display on these interface has to be of equally high quality. The recently released dutch building register for example contains a building that is roughly 320km² big !

So with all these great techniques and available datasets we actually create more confusion! The techniques assume that everybody understands the visual representation, while the datasets are expected to be correct. In my previous blog post I already expressed my concerns about opendata.

Pushing all the data and information into one representation is done to generate a context for it. Most bits and pieces of data and information have no context themselves, deep knowledge of its structure is needed to be able to understand it. So what could we do if the bits and pieces of information supplied actually contain the meta-data to describe them? Then we could use intelligent software agents to collect those bits an pieces of information which are needed for our current situation and present them in a way that makes sense to us, and doesn’t assist in creating confusion!

The technique to include the meta-data is called linked data, linked data contains the vocabulary to describe it, and is machine readable. Another important feature is the linking to external datasets, which allows us to infer relationships and automatically enrich the data with these external sources. Since linked data is  machine readable it’s very suitable to be processed by intelligent software agents, who can collect information based on the needs of the operator and the context they have to operate in. Another important feature of linked data is the distributed nature, we do not have to generate a large data management solution that contains all the information we might need, we simply reference external sources which are being kept up to date by their respective owners.

Fire department Amsterdam-Amstelland is using linked data already to assist in creating a small assistant for navigation, this is already described in previous post.

Afraid for Open Data

After visiting two Open Data related events in Amsterdam, Apps4nl and Open Innovation Festival, I found myself being afraid of what I had to conclude after these events. This might raise some eyebrows, coming from someone who claims to be a Linked Data enthusiast, and then blogging about being afraid for Open Data.

The primary reason that got me started with Linked Data were the problems I saw with the lack of operational access to information. When I needed to explain this problem to the board of directors of the Fire Department Amsterdam I had to explain this in a non technical way.

My fear

To express the problems I saw in the current situation of information management at operational level, I decided to formulate it as a fear:

During an operational incident an accident will happen where me or one of my colleagues will get injured or killed. Then after an investigation we will come to the conclusion that we had all the information available to prevent the accident from happening, but we just did not have the means to access it.

I considered this to be a very bold statement. But to my surprise it was acknowledged by some of the board members and I got green light for my experiments. Although we primarily focused on the data available in the organization, it is not that hard to draw the exact same conclusion for data available at the partners of the Fire Department.

The fear basically consists of two parts:

  1. Although the data might be available, the interfaces and devices at operational level are not capable of accessing it
  2. The information is available but not accessible digitally by machines to be used at operational level

Point 2 is exactly where the whole open data movement comes in to play. Wouldn’t it be great if we could access partner data while we drive to an incident? Let me illustrate this with an example.

If buildings are under control of Fire Department Inspectors because of their usage it should be possible to get the status on those permits in the organization. However there are numerous situations where the Fire Department does not require a permit for the building. That of course does not mean there are no problems with the building. If they would be able to access this information straight at district level they could solve this problem.

I am aware of a project in the Netherlands called DBK “Digital Object Map” which promises exactly that, but does so in a traditional closed model legacy system. That might have worked about 6 years ago, but with the current high interest for Open Data movements, it is smarter to ride that wave instead of forcing all the different districts, we need to deal with, to use a single purpose proprietary system.

So now that data becomes available, what is it that I am so afraid for? The current approach a lot of local governments take is the ‘Over the hedge’ method, we extract a dataset from our systems, put it on-line free to use, problem solved. That is not going to help us as this means we always have to rely on two important factors, the data is updated frequently, and we implement the changes in the right places as well. That is not a sustainable way to make me feel save again.

Linked Data

If a Fire Department wants to literally put the lives of their Fire Fighters in the hands of data, they cannot accept that the data they use is based on an occasionally exported dataset of which they hope the latest version is made available. There needs to be a possibility to query the source of the information directly, which will expose a dataset that is self explanatory, or at least gives the possibility to infer the relationships in that dataset . That dataset should of course reflect the real time situation of the source data!

Steps to take

It is really great that so many governmental organizations are opening up their data of course, but now that this topic is so high on the agenda we should dare to take the final step as well! Link the data! Make it sustainable and not just a simple dump. Only then organizations like the Fire Department Amsterdam-Amstelland can really take full benefit of all the efforts that have been put in this Open Data movement.

Linked Data Now!


How it all started, answers to questions that weren’t asked.

About 3 years ago a group of fire fighters at a fire station in Amsterdam was confronted with a new navigation assistant in the fire truck. From a conceptual point of view the idea of having navigation assistance in a fire truck might be nice, but there are practical implications when using a system designed for normal traffic in an emergency vehicle , remember fire trucks are allowed to defy all the rules in traffic! Without elaborating on why it is not working as it should, the more abstract point is that it gives answers to questions we never asked.

The answer you get from a navigation assistant is based on the question ‘What is my next step in getting to my destination?’ where fire fighters are more interested in ‘What is my final destination?’. Sitting down and discussing the subject the conclusion was that they were interested in an overview on a map with both the location of the fire station as well as the location of the incident marked.

The route itself is not that interesting as the knowledge of the fire fighters about the local area is at such a high level that they easily beat a navigation assistant.

To solve this problem, we were confronted with a few technical requirements:

  1. Real time, the system has to respond to an alarm at the fire station in a few seconds.
  2. It should not require any manual interaction.
  3. Low maintenance at station side.
  4. We should have access to the raw data

Items 1, 2 and 3 were pretty easy to solve, item 4 however turned out  to be a more challenging one.
Although the full message was sent ‘over the air’ via a paging protocol, it wasn’t really a structured data format. It was just a compression of various seemingly random chosen fields into a maximum width of 140 characters.
After some trial and error we were able to extract the various fields with about a 98% accuracy. Now that we had the data and the various pieces of information we needed to distribute this data. In our team we had some discussions about what format to use.

During that time we got introduced to RDF, where the flexibility of the data model was what was intriguing us most. This would perfectly fit with requirement 3. We could still enrich the data dynamically without breaking already installed systems at the fire stations.

How does it work now

After tying all loose ends together the structure of the solution is very elegant and simple.

  1. We scan the via air broad casted message for station ID’s we are interested in. Whenever a station ID we want is detected we generate RDF data.
  2. The vocabularies used are partly standard, partly domain specific.
    The standard ones include:

    • Meta data, all the information about the publishing of the data,who/when/where/what: OWMS / DCMI
    • Events, the alarm is an event, and we record everything relative to the event: SEM
    • Location, the crew is dispatched to a location: GEO
    • Address, the incident takes place at a certain address: vCard

    The domain specific vocabulary is a subclass of event, describing:

    • Units dispatched to the incident
    • Fire station involved
    • Deployment plans used.
  3. This information is stored as RDF data on a public URI. This URI is then dispatched to the relevant fire stations.
  4. The software at the stations uses Semantic Web techniques to retrieve the data from the URI, and show the relevant information on the map.


Due to the flexible structure of the data model we have been able to enhance and update the data model without touching the client software. If the clients needed additional functionality it needed a software update of course, but the software update was not necessary to accommodate a data model update.

From a Semantic Web point of view we now start very early in the incident describing the data, we actually do know what we are talking about. Because we gain knowledge about the actual incident at a very early stage we are able to assist and connect multiple sources of information in a later stage.

From a non technical point of view we have some results we didn’t expect. Because the truck driver now has a better idea of where he needs to go, he is more relaxed and better concentrated behind the wheel, resulting in more secure and save driving.
As there is a map at the station, the fire fighters look at the map more often, and get a better idea of their work area.

Outside in development

Due to the close connection with the people actually using the system, we were able to implement modifications and wishes really fast. We didn’t go through highly detailed project plans and endless meetings, but decided to start where we thought it was easiest and just took it from there, never loosing sight of the technical strategical direction we wanted to go and the targets to achieve.

Future plans

Our current focus now is to extend the screens with information from the deployment plans. More on that in the near future….


Our company,, has been active in the fire fighting business for over 10 years now. With a team of people, all close to or active in the job, we have learned a lot about how fire departments treat Information Technology. Over the years we have seen huge changes in the landscape of fire fighting and Information Technology. however is not very pleased with what we see right now.

In the current hype of open data and open government initiatives, fire departments are confronted with huge amounts of data. The enormous amount of attention that goes out to open data applications on various platforms clearly underlines the problem we are facing: we are just trading the open data for mirrors and beads, they are shiny and grasp our attention, but are not tackling the real problems.

To really leverage the gained knowledge in all the open data, we need to start to act now and understand the language we speak within the fire department organizations and align that with the new possibilities in the IT landscape.This modern structure of organizing our newly found knowledge is in need of a fresh vision at the methods we use to interact with all this data.

Over the past 4 years has been closely involved with our technology partner to develop a new framework for accessing information. You can find them under ‘technology partners’.

This blog is intended to share our ideas on how things should change in the fire fighting business, thereby improving the service to the public, reducing risks for the fire fighters and saving lives.