Development/Accordion test

aaaafffddddd

ffffddddee

hhdggdd__fffff__

Expanda

b

Expandc

d

Expanda

b

Expandc

d

ExpandWhy Mediawiki rather than Wordpress ?

Well, first Mediawiki is actually being used by the team behind Wordpress (Automattic) for their developer documentation as proof of the uniqueness of its features. Then, because the business model of Mediawiki and Wordpress are completely different. Wordpress allows an easy use but as soon as you want to expand or complete your website you are pushed (or constrained) to adopt paid solutions. Mediawiki (as well as our platform) is completely free, including any desirable advanced feature, at cost to deal yourself with the code (starting from wiki text itself, and proceeding with the creation of dedicated extensions). Then, because the intrinsic anti-immediacy of Mediawiki constrains the creation of quality of contents: dealing with the wiki text (either created through the help of visual editor, or directly) on the one hand slows down the content creation, and on the other provides you with a set of formatting and structuring tools specifically aimed at quality and complexity. Then because Mediawiki offers a strong versioning controlling and allows a collaborativeness that Wordpress is not able to offer: many people can work on the same content in the same time, and notwithstanding the integrity of the content is preserved, and you can access all the changes made by each of editors at any time. Finally because through the general design of our platform (where Mediawiki is used as back-end site) the presentation of contents (i.e. the appearance of the website) can be completely decoupled by contents themselves: a part of your team can solely take care of contents, and their organization or pages structure, and another part of the team can design whatever data consumer application querying the APIs, and to use the data and the semantic data returned by it, in any conceivable way, apart from creating client-side applications, of course for data visualization as well.

ExpandWhy a platform representing the Italian culture is conceived in English ?

Well, surely because English is the lingua franca of our times. Then because the native language of world of technology, to which this platform refers to, is English. Then because this would be also a demonstration of the ability of a kind of "Italian culture" to speak a technological language without diverting from its authentic nature, which being intrinsically humanistic, should not interpose hiatuses or ditches between disciplines and their languages but to pursue a universal vocation. Then of course because the audience for this platform is meant to be international, that is able to speak only partially Italian language, in such a way that where they will experience that a distinguished (not trivial, nor anonymous) English language originates from a specific wit of the Italian culture itself, they will be inclined to study and to learn Italian not only because it stands at a specific position in the rank of world's most studied languages (for whatever reason) but for its inclusive and possibly universal character, therefore providing the feeling of being at the center of cultural changes of our times. Then because the aim of each language is poetry, in such a way that expressing oneself in a foreign language (rather than in the mother tongue) refrains precisely from doing, or is ultimately expected, poetry, and allows to write in a rather plain way focusing on contents (that is on a stiffened form of expression) limiting one's own activity within conventional limits, ultimately productive in the daily life.

ExpandHow the front-end counterpart of this site is created or updated?

Well, while the back-end side of this platform is built upon a traditional technology (specifically Apache/PHP/MySQL) the front-end side is built on Node.js, eventually Nginx, and a client side Javascript framework based on Vue.js like Quasar framework. The latter side is fueled with data retrieved from Mediawiki (a forked version with some extended features, mainly an enhanced support for a non-flat namespace that is with sub-pages and sub-folders) through a Node.js script triggered every time that a page or file is created, updated, moved and deleted, and autonomously checking the mediawiki database with a specific frequency for any other indirect change (for instance when pages are imported through the mediawiki import page, or after the execution of some maintenance script). By this way, we can ensure a real time synchronization between the two sides on direct page's editing, and an accurate synchronization "within minutes" when the wiki site is updated in some indirect way. During this process the Node.js script performs some convoluted operation structuring data in such a way that they can be retrieved or even "consumed" by a front-end interface in a way that would not be possible without some intermediate operation and a further elaboration of data (for instance such infrastructure allows offline navigation through consistent set of pages). In short the front-end application (which of course is built ad hoc for this purpose, and is subjected to a development process completely decoupled by that of Mediawiki, even if the inter-dependency of the two is taken into account) retrieves its data through a dedicated API from a specific Node.js back-end, and these data are continuously updated and structured following the changes performed on the Mediawiki back end.

ExpandWhy Mediawiki rather than Wordpress ? (again)

Because the ultimate aim of this platform is to organize and structure significant data ensuring interoperability and a frictionless dissemination in the public domain (under specific terms, or after a specific amount of time) in such a way that Mediawiki has been chosen for its complementarity with Wikidata which aims to represent a common platform for the world's repositories of semantic data, and possibly to participate with its development. In this sense Mediawiki is an open platform and an open archive through which data recorded therein are not registered in an arbitrary or proprietary data structure, but in a universal vocabulary (or they are conceptually prone to be so) which can be understood potentially by every one: where of course we don't mean a limited set of specific enterprises holding the data ingenuously provided by users at the expense of their lives.