## 4 Results
### Business Processes  
The AZON platform is a set of cooperating elements, performing tasks according to the modelled processes. One of the implemented is the process of depositing and publishing data records (DPDR). Figure 3 highlights the states a data record may reach in it. An important aspect to consider when building a digital repository is the quality assurance of the resources deposited. In the case of resources already published, their evaluation can be implemented in various ways, ranging from providing mechanisms for ranking resources through the like/dislike options made available to users, to allowing for broader pros and cons commentary. There are also formal methodologies that involve evaluating resources using a validated rubric by trained teachers [22]. However, the quality of the resources deposited in the AZON platform is ensured by the editorial/review tasks run within the DPDR process. Thanks to them, records reviewed by specialists are subject to publication. Moreover, there is an opportunity to comment on already published records (_Helpdesk_ handles such comments). Figure 2: An outline of the logical architecture of the AZON platform. A user depositing a data record may attach any number of data files to it. Two possible options are: (i) direct upload, using the HTTPS protocol, and (ii) indirect upload, using the webdisk service, operating within the same infrastructure, supporting CIFS, SFTP, HTTPS protocols. The existing web servers' limitations enforced the distinction between these two cases. HTTP specification itself does not impose any specific size limit for posts. However, the receivers of the request (webservers) might not be ready to process large payloads. The limit is usually set at 2 GB level, which is not enough for transferring large movies. The automatic multimedia processing (processing of attached files to the data record) occurs when the data record reaches the _Published_ state and its _InSupplementation_ substate. The _Supplementation_ block in Figure 4 represents it. However, the necessity of multimedia processing may appear at other states as well (data files have to be recorded, named, encoded and uploaded, converted to long supported formats, optionally anonymized, prepared for presentation and preview, etc.). These steps are intentionally not shown in the figure to preserve its clarity. As depicted in Figure 4, several instances of _Supplementation_ might be executed in parallel by the _Depository Subsystem_ (AZON is a multi-access platform, and several users can submit their data records for publication simultaneously). According to the _Supplementation_ block's internal control flow, processing tasks are registered in the _Queuing system_, and results are retrieved and dispensed once specific business rules are met. The _Queuing system_ does not process any multimedia by itself during queued task execution. Instead, it delegates processing to the external systems by sending proper requests (see _Execute task_ block). Then it collects results. Figure 3: Diagram of states of data records deposited and published in AZON platform. The ad-hoc subtasks _Extract text elements_ and _Transcode audio/video_ require some explanations. The _Extract text elements_ subtask relies on the generation of transcript and subtitles in an appropriate format (STR, VTT, STL) for selected audio/video input through API calls to the Limecraft cloud service. Two scenarios are possible:  
* simple, by sending original audio to the _Limecraft_ cloud for processing, and downloading processing results. The processing flow starts with a POST request parameterized with file name and size. In the response, _Limecraft_ returns URL API for file upload. After receiving the information about the upload end (send through API), _Limecraft_ starts the transcript generation process and makes their results (transcript, subtitles) available in selected formats.