IDISS team has a challenge to solve: enhance data portability of standards for any structured data (XML). How? Find out in this interview with the team member Svante Schubert!
Can you briefly introduce yourself?
My name is Svante Schubert, just turned 50, living with family in Berlin, where I work since 2011 as a freelancer. Earlier I had been 12 years employed as Software Engineer at Sun Microsystems in Hamburg working on StarOffice (later being called OpenOffice and LibreOffice). During that time, I learned to work on software standards (being the blueprint of software) and I am still involved in the ODF standard – ODF being the office file format supported by many office applications – as co-chair of the technical committee at OASIS. As part of the EU digitalization efforts, I have added 7 years ago the domain of e-procurement to my field of experience, where I am now a co-editor at CEN TC 434 on the EU e-invoice format (EN16931).
What is your motivation to work in the data portability field?
My motivation is to reduce the pain I am experiencing nearly every single day due to the lack of digitalization. For instance, one of my main pains is doing the tax (for procurement, I must type data into my procurement software and, some months later, I am typing the same data into my tax software – this drives me crazy!). So much redundant, time consuming, error-prone work with the lack of running statistics across all data! This must change, and the solution should be applicable to all domains! Therefore, I am working on high-level ideas & tools to break free from this vicious circle.
How did you hear about DAPSI and what drove you to apply?
A friend told me about the DAPSI project before the 2nd project’s deadline. Sure, it is impossible to work out a solution for such complex ideas quickly, but I had faced the EU digitalization problem for years as an editor working on the EU e-invoice and coincidentally just two weeks earlier I was working on a definition of digitalization with the German Ministry of Finance.
I saw there was a chance to solve a big problem that I would otherwise never have to opportunity to solve!
In simple words, what challenge does your project address?
A tool to enable accessing data pools of similar data (ETL), by bridging different syntax by their equal semantic.
This project is starting to assist creating interoperable specifications/standards.
The base requirement of high-level digitalization.
What solution are you developing?
I realized that there are multiple levels of quality on digitalization and people not necessarily referring to the same. Taking the e-invoice digitalisation as an example: For some, the photo of the invoice is already digitalization. To me, the first step of digitalization is automated data access, which the photo does not provide. There are more requirements. Our EU thump rule for digitalization is “to be able to throw data over the fence and the receiver should be able to access it automatically without earlier bilateral agreement”. This can only be achieved by international standards, the blueprints of software. But I painfully realized that this is not enough. It does not solve our problem of data silos and the “not-invented-here” problem, which unfortunately exists also in the world of standards. There are so many forks and so little merges. Therefore, our DAPSI tool – we coined IDISS – is to assist merges: To build a bridge among similar standards, by offering a tool to align a set of equal semantics – a unique high-level user semantic – to each syntax. We call this a “syntax binding” in EN16931.
What will be the next steps?
We are supporting XML syntax and only EU CEN semantics of the EU e-invoice in our Minimum Viable Product (MVP).
We will show our MVP to potential users and let their needs drive our development. As after passing all milestones – and building the project with support of EU money – we aim to continue to bootstrap our project by the demands of the market, as we need to finance future development by users & customers to improve the tool’s usability & power.