{'fraction_non_alphanumeric': 0.016194331983805668, 'fraction_numerical': 0.0010121457489878543, 'mean_word_length': 5.104938271604938, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
ADJUSTING WSMO API REFERENCE IMPLEMENTATION TO SUPPORT MORE RELIABLE ENTITY PERSISTENCE 1

In the presented paper we scrutinize the persistence facilities provided by the WSMO API reference implementation. It is shown that its current file data-store persistence is not very reliable by design. Our ultimate goal is to explore the possibilities of extending the current persistence implementation (as an easy short-run solution) and implementing a different persistent package from scratch (possible long-run solution) that is more reliable and useful. In order to avoid "reinventing the wheel", we decided to use relational database management system to store WSMO API internal object model. It is shown later that the first task can be easily achieved although in not very elegant way, but we think that the later one requires some changes in the WSMO API to smooth out some inconsistencies in the WSMO API specification in respect to other widely used Java technologies and frameworks.