Towards Multilingual Haikus: Representing Accentuation to Build Poems (2025)

Abstract: The paradigm of neuro-symbolic Artificial Intelligence is receiving an increasing attention in the last years to improve the results of intelligent systems by combining symbolic and subsymbolic methods. For example, existing Large Language Models (LLMs) could be enriched by taking into account background knowledge encoded using semantic technologies, such as Linguistic Linked Data (LLD). In this paper, we claim that LLD can aid Large Language Models by providing the necessary information to compute the number of poetic syllables, which would help LLMs to correctly generate poems with a valid metric. To do so, we propose an encoding for syllabic structure based on an extension of RDF vocabularies widely used in the field: POSTDATA and OntoLex-Lemon.

## introduction neuro-symbolic artificial intelligence is a hybrid paradigm which combines both symbolic (e.g., semantic technologies such as ontologies and knowledge graphs) and sub-symbolic (e.g. neural networks and transformer-based large language models or llms) methods, trying to leverage the advantages of both of them @xcite . to develop neuro-symbolic artificial intelligence applications, we have proposed an architecture (illustrated in figure 1 ) for hybrid intelligent systems called haiku (hybrid artificial intelligence on knowledge and linguistics) @xcite . the main knowledge of the system would be stored using ontologies (as schema) populated in knowledge graphs and linked data (possibly including linguistic linked data, lld), but the system would also leverage transformer-based nlp models offering various services, such as user communication. the communication is bidirectional: nlp services can improve the semantic knowledge base, and semantic knowledge can improve nlp services. the motivations behind the haiku architecture are the limitations of both natural language processing (nlp) systems and semantic-based systems when they do not cooperate. for example, although llms are a useful tool in many cases, they typically perform better on english than on other languages, and the situation worsens even further for dialects or minority languages @xcite ). as a concrete example, by playing with the name of our architecture, let us consider the problem of obtaining a haiku in spanish, which requires a correct use of syllables in poetry. a haiku is a japanese poem with 3 lines of 5, 7, and 5 poetic syllables, respectively. we asked chatgpt-4 (the most recent free version, at the time of writing) to write a haiku about heavy metal music, in english. the answer "riffs shake earth and sky, thunder roars, hearts pounding wild metal gods arise" correctly respected the metric of haikus, but when repeating the same query in spanish, the answer "hierro y trueno va, el grito rompe la noche, fuego en el altar" was made up of 3 verses of 6, 8 and 6 poetic syllables, respectively, which is incorrect as a haiku 1 we also tried to refine the answer of the llm. firstly, we asked it to explain how the metric syllables were computed. since its answer was incorrect, we pointed it out some mistakes (the word "hierro", iron in spanish, has two syllables and words ending in "l" do not form a synalepha foot_1 ) and asked it to provide a new answer, which was again incorrect, having 4, 8 and 5 poetic syllables. even after a third iteration where we pointed out some errors, the answer was still incorrect as a haiku, having again 4, 8 and 5 poetic syllables. details about the experiment can be found in appendix a. of course, it is not desirable to expect the user to provide the division of a verse into poetic syllables, neither as part of the initial prompt nor by asking the llm to refine the answers. our aim is not to criticize existing llms (indeed, we only considered a single llm to illustrate our claim), but to point out that future intelligent systems must be able to know things like the correct number of poetic syllables in a verse. this could be implemented directly in the system or it could use an external service. in any case, we claim that the use of linguistic linked data @xcite ) (lld) would help to solve this problem: lld would provide the system the necessary information to compute the number of poetic syllables correctly. the objective of this short paper is to present a possible data representation based on lld that can express all the relevant information needed to compute the number of poetic syllables in spanish. the remainder of this paper is structured as follows. section 2 provides some background on poetic syllables in spanish. then, section 3 discussed our modelling. finally, section 4 sets out some conclusions and ideas for future work. ## poetic syllables in spanish computing the poetic syllables of a verse in spanish foot_2 requires the following steps: if a word is written with an accent, by separating it into syllables we can easily see whether it is proparoxytone, paroxytone, or oxytone. if the word is written without an accent, it will be oxytone if it ends in a vowel, "n" or "s", otherwise it will be paroxytone. the procedure is similar in other romance languages (e.g., italian and galician). in some languages (e.g., french and catalan), there is a notable difference: only the number of metrical syllables until the last stressed syllable is taking into account, but one still needs to know whether the last word is oxytone, paroxytone, or proparoxytone. in principle, in order to both calculate the number of syllables in a verse and to check whether a word with a written accent is proparoxytone, paroxytone, or oxytone, a syllabification algorithm would be needed, that is, one that separates a word into syllables. implementing these algorithms is not easy and requires deep domain knowledge, due to the large number of possible exceptions. an alternative is to use a linguistic knowledge base where each word is already separated by syllables. additionally, the knowledge base could also indicate for each word whether it is proparoxytone, paroxytone, or oxytone: without being strictly obligatory, it would increase the efficiency of the system by avoiding having to calculate it. for example, we could use a pronunciation dictionary such as @xcite , which represents the spanish word "uva" (grape) as "oo'-vah", where the hyphen separates the syllables ("u" and "va") and the apostrophe indicates the stressed syllable ("u"). that dictionary exists only in paper form, but even if a version of it were available in digital format, it would most likely be only in a humanbut not machine-readable format, such as html or pdf. in order to make it useful for llms and other non-human consumers, it would be desirable to have a representation in a more machine-friendly format, such as rdf and have it accessible via a sparql endpoint. ## lld-based solutions in this section, we will discuss lld-based solutions to represent the syllables and the stressed syllable of a given word. typically, lld use rdf foot_3 , a w3c standard framework for representing information. although rdf can be serialized into different formats, we will use turtle syntax, which is more easily understandable by humans. for example, the triple 's p o ." states that a subject s is related with an object o via a property p. postdata. as a basis for our modelling we reuse the set of ontologies created in the post-data (poetry standardization and linked open data) project @xcite . in particular, the postdata-structural (pdstruct) 5 and the poetic-analysis (pdp) foot_5 ontologies to represent the basic structure and the literary analysis properties, respectively. using postdata, we can represent words as instances of the class pdstruct:word and grammatical syllables as instances of the class pdstruct:syllable. each word is connected to the first and the last syllables that form it via the object properties pdstruct:hasfirstsyllable and pdstruct:haslastsyllable, respectively. furthermore, each syllable is related to the next and the previous one via the data properties pdstruct:nextsyllable and pdstruct:previoussyllable, respectively, which makes it possible to navigate through all the syllables of a word. for a given syllable, pdp:positioninword is a functional data property with an xsd:integer value to represent the position of the syllable from the end of the word (e.g., 1 for the stressed syllable of an oxytone word, 2 for the stressed syllable of a paroxytone word, 3 for the stressed syllable of a proparoxytone word, etc.), as illustrated in figure 2 . however, it is not possible to represent whether a pdstruct:previoussyllable is stressed or not foot_6 . to do so, one must use metrical syllables. the class pdstruct:line makes it possible to represent a line of a poem and, for a given line, pd:hasmetricalsyllablelist retrieves a list of metrical syllables. given a metrical syllable, pdp:isstressed is a functional data property indicating whether the syllable is stressed or not using an xsd:boolean value, whereas pdp:metricalsyllablenumber is a functional data property using an xsd:integer value to represent the position of the stressed syllable from the end of the line. this is illustrated in figure 3 . while using lines is suitable for poems, it is not possible in our case since we want to encode a list of words with their syllable structures. it is possible to represent each word in the dictionary (e.g., "uva") as a line (pdstruct:line), buth this is highly undesirable. furthermore, to encode the stressed syllable, grammatical syllables would have to be represented as metric syllables, which is also not the ideal situation. note indeed that the division of a word into metrical syllables might not be unique, as authors could use poetic licenses such as synaeresis, diaeresis, or hiatus. two new properties. as a solution to the previously mentioned limitations of postdata for our use-case, we propose two new properties haiku:tonicsyllable and haiku:hassyllables, where haiku is a new vocabulary: ontolex lemon. so far, we have proposed to use two novel properties that state some information about a word, but the representation of the word has not been discussed in detail. one option would be to use ontolex-lemon model, a w3c vocabulary that provides rich linguistic grounding for ontologies and is a de facto standard to represent lexical resources such as dictionaries as rdf data @xcite . in particular, the domain of the novel properties can be ontolex:form, a class that represents a surface form of a lexical entry. in our case, this can be used to point to the canonical form of a word. 8 therefore, haiku:tonicsyllable property links (the canonical form of) a word to a numeric value representing the stressed syllable, whereas haiku:hassyllables property links (the canonical form of) a word to an (ordered) list of grammatical syllables represented as strings. figure 4 shows how to associate the hyphenation and accentuation to a word encoded in ontolex lemon. ## conclusions and future work in this paper, we showed how to use linguistic linked data to represent the necessary information to compute the number of poetic syllables in spanish. while existing vocabularies such as postdata are appropriate to represent the metric syllables of an existing poem, they had to be extended for our purposes. therefore, we proposed two novel properties to represent the hyphenation and accentuation of a word, which could be represented using ontolex lemon vocabulary. the next step is to support intelligent systems in the automatic generation of poems with a valid metric. for this, linguistic linked data could be used for knowledge injection in existing large language models, improving them. this illustrates the usefulness of our approach within the field of neurosymbolic artificial intelligence. in future work, apart from the actual application of our vocabulary for knowledge injection in llms, we could generalize the vocabulary to support different languages. while our novel properties are enough to infer the number of poetic syllables in spanish, other languages might require different information. furthermore, other types of metrics apart from haikus might be considered. thus, our novel vocabulary is intended to be generalized with more properties, if needed.