Step 1 – Design the extractors (~10 minutes) Step 1 – Implement the extractors (many days of trials and errors)
NOTE: Deleted text means that we did it during the first integration attempt with the old platform versions, due to the limitations of the previous API. Don’t try this at home!
We immediately started integrating the components. In order to perform integration in a manner that could be reused in the future, we decided to put a bit of thought into the component design first. After all, the goal was to develop a new back-end to be used for existing and future components developed within the AudioTrust+ project.
We selected three specific AudioTrust+ components, developed in C++, which have a straightforward interface:
- One input WAV file
- One output XML file, compliant with its respective AudioTrust+ XSD
- A few input parameters
We did not want to modify the APIs of the underlying components, and hence decided to encapsulate them separately, in three different MICO extractors. More specifically, three C++ extractors (because we do not like JNI we did not want to create JNI interfaces) with the same interface as the underlying Audiotrust+ components.
In order to transform the XML output into RDF, we decided to rely on a separate Java extractor component — following the “annotation helper” paradigm used to create the existing MICO pipelines –, which is only responsible for parsing the XML output, and writing the RDF annotations. The interface of this extractor only consists of:
- One input XML file, which is conform to the AudioTrust+ XSD definition
- Several output RDF annotations
After defining the interfaces, we double-checked the MICO API, and found out that there was no possibility of defining any input parameter in the extractor call!? since the release of the MICO platform version 2 any extractor can have several input data, output data, and input run-time parameters. Everything was alright, and we could move on!
