The SONICOM Ecosystem
Welcome to the SONICOM Ecosystem Wiki!
The objective of the SONICOM Ecosystem is to create a web-based data repository having the following properties:
- Storing auditory data linked with model implementations and tools for binaural rendering
- Integrating the output of SONICOM
- Registered in re3data.org and integrated in an institutional data repository
- Open-accessible, documented
- Searchable by metadata via a web frontend
- Visualizing the data specific to our research topic (spatial hearing)
- Providing an interface for machinable download of partial data
- Enabling other stakeholders to contribute and interact
An important objective is to create a clearly defined unique added value with respect to other general repositories. In the case of the Ecosystem, the unique added value is the focus on personalized binaural audio and research in spatial hearing. A prominent property demonstrating that focus is the visualisation of the data specific to our research topic of spatial hearing.
Technically, the Ecosystem consists of two parts: the frontend and the backend. The frontend is the web application visible to the user. It is accessible via the link https://ecosystem.sonicom.eu/ and the main interface when browsing and contributing the data. The frontend is run on dedicated hardware at the ARI and maintained by the institute’s IT group. This enables quick response time in case of troubles or IT support. The development of the frontend done by the OeAW team from scratch, providing custom-made solutions (to reach the Ecosystem’s goals) and enabling open-access publication of the code. The frontend also handles the user management and the interaction with the auditory community. However, the frontend would be too volatile to provide sustainability required to provide DOIs. Also, integration of own repository into all the automatic metadata indexing services (e.g., DataCite Metadata Store, OAI-PMH, search engines, etc) would be just too time consuming. Hence, registration of DOIs, meatadata indexing, and the compliance with worldwide search and archival systems is outsourced to the backend.
The backend is a general-purpose data repository run by the AASP and called “Datathek”. The Datathek is available via https://datathek.oeaw.ac.at/en and designed as a multidisciplinary repository for archiving and publishing research data generated by members of the OeAW or research in connection with activities of the OeAW. The focus is on research data from subjects that do not yet have their own discipline-specific infrastructures for research data management. The Datathek assigns a DOI to each published data package. It guarantees a secure storage period of at least 10 years for published data. The Datathek provides an API that allows services to be programmed and offered via a dedicated user interface. In the Ecosystem, this API is used as the link to the frontend.
Within the Ecosystem concept, the user interacts with the frontend only. There, while contributing a new data, the user provides the metadata and data. Then, the user can trigger the process of publishing with the DOI. To this end, the frontend transfers the metadata and data to the backend and requests a publication with a DOI. If accepted, the backend publishes the data, activating the DOI available for access. At the frontend, the data will be locked and shown with the activated DOI.
Note that the user is expected to interact with the frontend only. The exception is accessing the data via the DOI, in which case the user gets relocated to the DOI landing page, which is a Datathek page at the backend. To easily bring back the user to the frontend, the Datathek landing page shows a back link to the corresponding resource at the frontend. This is important because the backend displays the data in a general form. Once redirected to the frontend, the user can experience the data research-specific visualisation. This way, the Ecosystem provides both the focus on the research field and the sustainability provided by a general-purpose data repository.
The backend is the Datathek, a service created (for the Ecosystem) and operated by the Austrian Academy of Sciences Press (AASP), which has extensive experience in running the OeAW´s institutional repository EPUB.OEAW since 2006. The server is operated and locally run by the OeAW´s IT department ARZ. The data is physically stored on local servers at the ARZ and at an external ISO-certified data centre.
The Datathek is based on the RADAR software, which is a cross-disciplinary repository for archiving and publishing research data from completed scientific studies and projects. The focus is on research data from subjects that do not yet have their own discipline-specific infrastructures for research data management. For the Datathek, RADAR was set up and is maintained by “FIZ Karlsruhe”, part of the Leibniz research organization and partner in the German National Research Data Infrastructure (NFDI).
The data published in the Datathek is given a DataCite-DOI. This allows it to be uniquely identified and cited globally. The Datathek offers interfaces to ORCID, ROR, Crossref Funder Registry, GND, and OpenStreetMap. It provides a well-documented API, usage data, metrics, metadata export (the options include: JSON, Bibtex, Schema.org, Endnote and many more). Further, the Datathek is registered at the worldwide registry of research-data repositories re3data.org. The data stored in the Datathek is indexed by OAI-PMH, RADARcloud, and DataCite. It stores data by following the FAIR data principles, which are a set of guidelines for making research data Findable, Accessible, Interoperable, and Reusable. These principles aim to improve the discoverability, accessibility, and reuse of research data, both by humans and machines.
The frontend is set up in two versions: the live version and the developer version. The live version is the frontend available to the user. It is well-tested and stable and contains all the data collected through its life time. It runs on specialized hardware embedded in a proper IT environment. The developer version is the fronted used to develop new features, fix bugs, and perform testing. This version is visible to the Ecosystem core team only and run on a standard VM server.
The live-frontend hardware will be physically located at the ARZ’s facilities. It will be integrated in one of the server racks located in a server room of about 40 m² containing all other servers run for the OeAW. The facility is designed for high-performance IT purposes: It has air conditioning, provides redundant power supply backed-up by uninterruptible power supplies. The access to this room is provided to the ARZ team only. The server room has a direct link to ACOnet, an Austrian-wide highly performant and non-overbooked fiber backbone network. The link is redundant, permitting highly stable and fail-safe network operations via 100 GB/s fibers.
The server hardware will be a 19” rack unit consisting of a mainboard, memory, CPU, SSD for the operating system, as well as network and data-disk interfaces. The mainboard will be the Supermicro Mainboard X12SPi-TF or similar. It offers 10 SATA-3 interfaces to data disks. It comes with two 10 GB/s network interfaces. It offers a full remote management via as KVM over LAN and IPMI 2.0. It will be equipped with 128 GB RAM and 480 GB SSD for the operating system and the code (Note that data will be stored on separated devices). It will be further equipped with a 16-core Intel Xeon Silver 4314 running at 2.4 GHz. This CPU power is required to process the data on upload (see Widgets below). The unit will also be equipped with two redundant 400-W power supplies, which will be hot-swappable.
The unit will be connected to disks. The required size obtained from the survey is 1 TB. Additionally, we planned to merge the data from our SOFA repository https://sofaconventions.org/ into the Ecosystem. The current size of the SOFA repository is 750 GB. Rounded up, this makes a requirement for disk space of 2 TB. With a factor of four for having future-safe disc space, we aimed at 8 TB disk space.
For the data storage system, we will use RAID 6, which is a storage configuration providing a high level of data redundancy and fault tolerance. It's an enhancement of RAID 5, designed to protect against more severe scenarios of disk failure. The high fault tolerance is achieved by implementing dual parity, i.e., calculating and storing two independent parity blocks for each stripe of data. These parity blocks are distributed across different disks in the array. The primary advantage of dual parity is its ability to withstand the simultaneous failure of two hard drives without any data loss. Further, RAID 6 uses data striping where data is broken into smaller blocks and distributed across multiple disks. This improves the read performance. Hence, our system will consist of four 4-TB SSDs running in a RAID-6 data storage setup, yielding 8 TB space for data and backups.
For the developer frontend, the hardware will be just some computer available at the IT’s group of our institute, providing access to a VM environment able to run the required software.
All the software is run in a virtual machine, providing flexibility and hardware independence. The software consists of the operation system with its configuration as a web server and of the actual frontend code.
For the operating system and its configuration, we use open-source components only. This offers long-term sustainability and flexibility if required. The operating system is Linux Ubuntu 24.04. Further, we use Ansible for package and user management as well as configuration of services. The webserver software is Apache version 2.4.57 with integrated PHP version 8.3.8. The live webserver is reachable via https://ecosystem.sonicom.eu/ worldwide, the developer webserver via http://ecosystem.amtoolbox.org/ just from internal VPN. In order to provide a secure end-to-end encryption between the Ecosystem and the user, we use Certbot to provide Let’s Encrypt SSL certificates. For the database service, we use MySQL 8.0, which can be accessed only from within our VPN and by the frontend code.
For the frontend code, both live and developer versions use identical software. The exception is that the developer version contains updates and upgrades to be tested before rolling out to the live version. We use GitHub for the code repository (without the operation system and its configuration mentioned above) and Git as the software versioning system. Both software versions are available as two distinct branches of the same GitHub code repository:
The code of the developer version is stored in the branch “dev”: https://github.com/sofacoustics/Ecosystem/tree/dev The code of the live version is stored in the branch “live”: https://github.com/sofacoustics/Ecosystem/tree/live
The development workflow is as follows:
- Users contribute to the developer branch.
- The developer version is being tested on the developer server.
- When having all tests passed, the code is checked-in to the live branch and released.
- The live release is then rolled out to the live server.
For the frontend code, we use the Laravel framework which is a free and open-source PHP-based web framework for building web applications. It simplifies the development process by providing tools and resources for tasks like routing, database interaction, and authentication. We currently use Laravel version 11.44.2.
Laravel follows the model-view-controller (MVC) architectural pattern, which is a software design pattern that separates an application's data, presentation, and logic into three distinct components: the model, the view, and the controller. This separation of concerns helps to create more modular, maintainable, and scalable applications. and offers a robust environment for web applications.
Our Laravel configuration considers additionally the following plug-ins:
- Reverb: Laravel Reverb provides the core infrastructure for building dynamic and instantly updating web applications. It enables real-time communication between the Laravel core and user-side application. In the Ecosystem, we use this right after the data upload to trigger the web browser to update the page once an image of the data has been created.
- AlpineJS: AlpineJS is a lightweight JavaScript framework that enables client-side interactivity on web pages directly within the HTML markup. We use it for dynamic reactions of a web page without the necessity to contact the server.
- Livewire: is a full-stack framework for Laravel that empowers developers to build dynamic and interactive user interfaces using primarily PHP and Laravel templates. It facilitates the creating of reactive web applications without the need for extensive, separate JavaScript frameworks. In contrast to AlpineJS, Livewire does contact the server, enabling more complex reactions. In the Ecosystem, we use Liverwire for all web forms, and, e.g., to filter search results while typing.
- Tailwind CSS: Tailwind CSS is a utility-first CSS framework that provides a rapid build of custom user interfaces directly in the HTML markup. Instead of providing pre-designed components (like buttons, cards, or navigation bars), Tailwind provides thousands of low-level "utility classes." Each utility class typically corresponds to a single CSS property or a small, focused set of properties. In the Ecosystem, we use Tailwind for layout and design of the user interface.
The software is further embedded in the GitHub development environment. We use the GitHub “Issue” feature to manage software issues such as bugs, feature requests, or questions about the development and testing. We further use the Github “Wiki” feature to provide the documentation of the Ecosystem.
In the Ecosystem, a database is a collection of metadata and research data. In the following, we describe the logical structure of a database, describe processes such as the data upload, the visibility management, the publication, and the download.
A database consists of datasets, which again consist of datafiles. Within a database, all datasets have the same structure, which is defined in the dataset definition.
We use the following terminology:
- Database: A database is a collection of metadata and data in a specific collation of formats, e.g., a collection of HRTF and images, where each database record contains one HRTF and one image of the ear.
- Dataset: A dataset is one record in the database, e.g., one HRTF and one image for one of the subjects. One record may contain multiple datafiles of various datatypes. The exact composition of all datasets in a database is given by the dataset definition.
- Datafile: A datafile is a file stored in a dataset. Each datafile must be a type available in the Ecosystem and can be visualized by a widget.
- Dataset definition: A dataset definition is a collection of datafile definitions and defines how datasets are represented in a database. For example, for each dataset to consist of two HRTFs and four images, the dataset definition needs to define six datafile types, four having the type set to HRTF and two set to image. Each of the defined datafiles can be represented by a separate widget.
- Datafile definition: A datafile definition defines the representation of a datafile within the dataset. It consists of name, description, datafile type, and widget for visualisation. For example, in order to store an HRTF in each dataset, the datafile definition needs to have selected “HRTFs” as datafile type.
- Datafile type: A datafile type is one of the predefined types of data which can be used in the datafile definition, e.g., “HRTF”, “BRIR”, “Geometry”, etc.
In order to create a complete database, the user needs to go through the following steps: Register and link with ORCID (see below).
- “Create a new database”: This will open the form to provide metadata. Note that there are some required metadata, which need to be provided in order to create a new database, and there are metadata required to publish the database. In the first step, only the first ones need to be provided. By providing the metadata, the new database will be created.
- “Definition”: This will open the form to define a dataset, starting the definition of a datafile. The user needs to define how a datafile will be handled within the Ecosystem by means of a name, type, widget (see below), and an optional description. A single datafile definition is obligatory, and multiple datafile definitions per dataset can be provided. To this end, the form iterates the user through the datafile definitions.
- Having the dataset defined, datasets can be created. This can be done by manually creating a single dataset and uploading the corresponding datafiles or in a bulk upload of many datasets at once:
- “Upload”: This will open the form to create a new dataset (by means of name and optional description). Then, the user is asked to upload the datafiles related with that dataset.
- “Bulk Upload”: This will open the form for a bulk upload of multiple datasets at once:
- First, the user needs to provide the local directory with the datasets.
- Second, the user needs to provide filter patterns to algorithmically create the names of the datasets and the filenames of the datafiles to be uploaded and assigned with the corresponding datasets. With “Apply filter” a table shows the assignments, including some statistics and list of skipped files. This way, the user can verify and adapt the filter patterns until the list of datasets is complete.
- Having the table complete, the user can select which datasets to upload and click “Start upload”. This will upload all the selected files to the Ecosystem. The progress is displayed and the success is shown on completed upload of the selected files.
- “Save files to database”: With the successful upload, the user needs to save these datasets to the database. This is the last but an essential step, completing the bulk-upload procedure.
- “Datasets”: This shows a table with the available datasets (after the upload).
Note that a new database is private, i.e., only visible to the user creating it. The visibility can be modified with the function “Manage Visibility”, see below.
Widgets provide the functionality to process uploading datafiles, store the results in a cache, and then show the results to Ecosystem users via the browser. Each Datafile can have a Widget selected, the selection happens on the Dataset definition.
The process is as follows: The upload of a file triggers two processes: 1) The storage of the file as a Datafile, and 2) The Service processing the file. Here, the Widget controls which Service is run. A Service is a pre-defined algorithm extracting some information from the file or visualizing the data in the file in some specific way. Currently, a Service can be any Octave or Python script. Note that Services cannot be modified or created by the users. Because of security reasons, new Services can only be added by the Ecosystem developer team.
The results of the Service are saved in the Cache. When accessing the Datafile while browsing, the cached results are shown to the user in a View. Both, the Service and the View belong together and are controlled by the selected Widget.
The Ecosystem provides some pre-defined widgets:
- SOFA: HRTF General: Visualize the energy-time curve of the HRTF set in the horizontal plane in an image, visualize the spectral amplitudes of the HRTF set in the median plane in two images (an image for each ear), the ITD and geometry. This widget works on SOFA files only and creates and shows 7 images.
- SOFA: BRIR Geometry: Visualize the geometry underlining a BRIR set in terms of the position of the ears and loudspeakers within the room. This widget works on SOFA files only and creates a single image.
- SOFA: BRIR Geometry: As “SOFA: BRIR Geometry”, but for microphones instead the two ears. This widget works on SOFA files only and creates a single image.
- SOFA: Directivities Polar: Visualize the directivities as a polar plot in the horizontal plane. This widget works on SOFA files only and creates a single image per frequency.
- SOFA: Metadata: Extract metadata from a SOFA file and display in a table. This widget can be used on any SOFA file.
- SOFA: AnnotatedReceiver: Visualize the position and orientation of the ears over time. This widget works on SOFA files only and creates a single image.
- SOFA: Headphones: Visualize the amplitude spectra of headphone frequency responses. This widget works on SOFA files only and creates a single image.
- Geometry: BezierPPM: The file is supposed to represents the parameters of the BezierPPM. and the service creates a mesh with the BezierPPM parametrized by that file parameters. The View is a plugin for the interaction with a 3D mesh.
Further, the following Widgets do not need a Service, but have a specific View:
- Geometry: Mesh: Show a 3D mesh and let the user interact with it.
- Image: Display an image, provide some basic operations such as rotation and zoom.
- Audio: Show a simple audio player, provide the option to play the audio.
- Properties: Display some basic properties of the Datafile such as the size, the date of creation.
- Image: Spherical: Display a 360° image and let the user interact with it.
Note that other widgets can be added if requested by the community.
The Ecosystem provides the download by means of the user going to the Ecosystem website and clicking on a download link and a client automatically downloading the requested datafiles.
The user can trigger the download of a specific datafile of a specific dataset by clicking on “Datasets”, then on one of the dataset names, then a click on one of the datafile names will triggers the download.
If the database has a DOI, the user can also download the whole database as a TAR file by clicking on “Download” and then selecting the link named “TAR format” (Note that this functionality is not provided at the Frontend yet, it is available from the Backend only).
A more convenient access to the data is provided by an interface to remote clients. This enables machinable download of specific datafiles or the whole database as a structure of datafiles. The machinable download is implemented as JSON files containing links to datafiles accompanied by metadata such that a machine can easily find the requested data.
Two types of JSON files are provided:
- A list of all databases in the Ecosystem: https://ecosystem.sonicom.eu/databases?type=json. Note that this link is provided on the landing page of the databases, however, remote clients can have this link hard-coded to access the list of all databases in the Ecosystem. This link returns a JSON file containing, per database, the database title, subtitle, production year, creation date, last update date, the database ID, and database URL. With the help of the database ID, the link to a specific database can be created. Or, the database URL can be used to directly access the database-specific JSON file.
- A database-specific JSON file: https://ecosystem.sonicom.eu/databases/ID/download?type=json, with the ID being the ID of the database, obtained, e.g., from the list of all databases, see above. This link returns a JSON file containing, per dataset, the dataset name, ID, and description as well as names, IDs, types, and URL of every datafile of that dataset. In the simplest case, the client can use that URL to download the requested datafile.
As examples, we provide the following code for the remote clients:
- databaseList: This code displays the list of all databases, including their IDs. This way, the user can get the ID of the database of interest.
- databaseDownload(databaseID, downloadPath): This code downloads the database given by databaseID to the local path given by downloadPath. The directory structure will be: downloadPath/datasetName/datafileDefinitionName/DatafileName.
- toolList: This code displays the list of all tools, including their IDs. This way, the user can get the ID of the tool of interest.
These clients can be downloaded from the Ecosystem webpage directly, or they can be found in the Github code repository: https://github.com/sofacoustics/Ecosystem/tree/dev/laravel/public/clients. We currently provide clients for Octave, Matlab, and Python, however, the clients are not limited to these specific programming languages.
The visibility and publication of the database is handled by “Manage Visibility”.
When a database is created, it is private, i.e., only visible to the user creating it (and the Ecosystem administrators). This facilitates careful input of metadata, collection of which can take a longer period of time.
The database can be exposed to others as soon as the user wishes to do so, which is most probably after having all the metadata clarified and correctly input. To this end, the user can click on “Expose” and after having the warnings confirmed, the database will be visible to everybody, even anonymous visitors of the Ecosystem. Hence, this step corresponds to a publication of the data. The only difference to a publication with DOI is that after having the data exposed, it still can be modified and the new datasets added.
After being published without a DOI, the database can be hidden again by clicking “Hide”. While this will hide the database and it will be visible only to the user who created it, note that because the database was publicly available in the meantime, privacy cannot be guaranteed.
The next step is to assign a DOI. This can be done by clicking on “Assign a DOI”. Note that this can be done only if all required metadata are provided. Technically, these metadata will be sent to the backend, they will be validated by the backend, the backend review process will be started, the DOI created by the backend, will be collected, and the review will be aborted. The DOI will be shown on the frontend.
Note that the transfer of the metadata from the Ecosystem to the Datathek involves a translation of the Ecosystem metadata to the RADAR metadata format. Thus, some additional metadata are created, with the prominent example of a related identifier describing the back link from the Datathek to the corresponding database in the Ecosystem. Some metadata are modified, with an example being the database title, which get a postfix describing whether it’s a database or a tool and including the Ecosystem ID. This is required because in RADAR, the title needs to be unique across all collections, while in the Ecosystem, the same titles can apply to database and tool, and also across the databases. The details of the metadata translation from the Ecosystem to RADAR are described ???.
Note also that assigning the DOI is irreversible – once assigned, it cannot be revoked or reassigned. The data and metadata can still be modified, though, as far as the database is not published with DOI yet. This way, the DOI can be assigned to be reported, e.g., in a paper-review process, while modifications of the datasets and metadata are still possible.
Once the data collection is accomplished and the database completed, the database can be published with DOI. The difference to having the database exposed is important: after having the database published with DOI, it cannot be modified anymore. The publication with DOI can be done by clicking on “Publish with DOI”.
Technically, the metadata will be updated in the backend, validated again, then all datafiles will be copied to the backend. There, we create a container with the same structure as for the download, namely, datasetName\datafileDefinitionName\DatafileName. Once the copying process has been completed, any modification of the data and metadata will be disabled and the Datathek curator will be notified to review the submission. If the Curator approves the submission, the database will be published at the Datathek and the DOI will be activated. If the Curator rejects the submission, the state reverts to that before starting the publication process and the user will be notified with Curator’s comments via email. Once approved, the database will be locked and published at the Ecosystem and the Datathek.
A tool is usually thought as a software, however, in the Ecosystem, a tool also can be:
- “Text”, which when linked to a specific database can provide documentation for that database;
- “Physical object”, which can be used to provide descriptions of physical objects such as headphones, loudspeakers, rooms, etc;
- “Model”, which can be used to provide code and data for a single model such as an AI model;
- “Other”, which can be anything but not a data (which is supposed to be stored as a database).
Most of the information provided for Databases applies to the Tools. Also, a DOI can be assigned to a Tool in the same as to a Database. However, the logical structure of a Tool is much simpler because it consists only of a single file and the metadata. The metadata are the same as those describing a database. The following differences apply to tools:
- No dataset, just a single file, consequently, no partial download. If a tool consists of multiple files, the user can locally store them in a ZIP container and then upload the container as a single file.
- No visualisation, consequently, no widgets, no services, no views. The metadata may provide links to external visualizations, though.
- No option to hide, a tool is visible right after having it created and uploaded. This is because the tool is added to the Ecosystem in a single step.
Besides these differences, a Tool can be thought as a simplified Database having a different purpose. By creating nearly the same user interface for both Databases and Tools, we hope to simplify the usage of the Ecosystem.
While everybody can anonymously browse and download the data, new contributions require a registration and link of the user to the user’s ORCID.
To this end, a new user, even when registered, cannot add databases or tools. They have to link their account with ORCID first. With such a link, their name and ORCID ID are retrieved from the ORCID system. This way, the actual name of the user is verified, and the research history of a user can be tracked back. With that measure, we hope to limit the pool of contributors to actual researchers and to reduce the number of fake registrations. Currently, the user can revoke the link to ORCID and modify the name. This would also post-hoc modify the displayed name of the person who uploaded related databases. This is an unwanted behavior and we will address that soon.
ORCID-approved users can comment on databases and tools. This way, feedback can be provided to the data creators. Also, discussions can be triggered, ideally, leading to data improvements or even creating new data and tools.
By providing the functionality to comment on the Ecosystem’s resources, combined with the ability of only ORCID-approved researches to fully experience and contribute, the Ecosystem fulfils the objective “Enable other stakeholders to contribute and interact”.
Note that the commenting functionality is currently quite rudimentary. Depending on the initial feedback, we might expand it in the desired directions.
For the service provided by the Ecosystem, terms of service have been established jointly with the Press and Legal departments of the OeAW. The terms of service are available for every visitor of the Ecosystem at https://ecosystem.sonicom.eu/terms-of-use.
In summary, the terms of service advise the visitors about the following:
- The SONICOM Ecosystem is a research-data repository, operated by the OeAW.
- It provides access to spatial-hearing research data.
- Its services, including archiving, web-publication, metadata assignment, and API, adhere to FAIR principles.
- It is open for non-military research data and offers various access modes, including private, embargoed, and open content.
- It is primarily intended for the archiving and dissemination of anonymized and pseudo-anonymized data. All users submitting data must ensure that research data originally containing personal data is either anonym, anonymized, or fully consent cleared.
- In order to address data protection, it acts as a data processor under GDPR for personal data handled on behalf of users contributing their data.
The terms of service further outline responsibilities and liabilities for the repository, data depositors, and users, stressing adherence to scientific practice guidelines. It also lists the technical and organizational measures, as well as the data subprocessors.