A Lightweight String Based Method of Encoding Etymologies in L inked D ata Lexical Resources (2025)

Abstract: In this submission we propose an approach to encoding etymological information as strings (“etymology strings”). We begin by discussing the advantages of such an approach with respect to one in which etymologies and etymons are explicitly represented as RDF individuals. Next we give a formal description of the regular language underlying our approach as an Extended Backus-Naur Form grammar (EBNF). We use the Chamuça Hindi lexicon as a test case for our approach and show some of the kinds of SPARQL queries which can be made using etymological strings.

## introduction linked data best practices encourage the use of http uri's to name things and representing every bit of information as rdf triples (statements) based on a formally defined data model. in other words, the preference is for modelling data explicitly in the form of knowledge graphs in which all or most of the entities are represented as rdf classes or individuals each with its own individual uri (individuals can be represented as blank nodes, although this limits their usability). however, certain kinds of data do not lend themselves easily to being modelled this way. this is the case for descriptions of dynamic or temporal phenomena: these latter are most naturally modelled via the addition of a temporal parameter to standard rdf subject-predicate-object triples something which, in general, can only be done via workarounds, e.g., via the reification of properties. linguistic linked data offers many examples of such dynamic phenomena, notably in the form of etymologies, i.e, hypothetical word histories @xcite . indeed, when it comes to etymologies, aside from the requirement to represent temporality we have a number of other modelling considerations that make the comprehensive description of such resources potentially very complicated from an rdf point of view. for instance, the following: in addition, in order to carry out a 'deep' modelling of etymologies, we should, according to linked data best practices, create uris/individuals for etymons and cognates as well as for etymologies themselves and for cognate sets, that is, to reify all of these elements, as well as adding other elements in order to represent the temporal duration of relationships and properties between individuals. a vocabulary that meets all or most of these requirements will end up being complicated and difficult to use, going well beyond the basic constructions and elements of languages such as rdfs and owl or more specialsed vocabularies such as ontolex (see for instance the proposal given in (khan, 2018)). in addition, such a vocabulary would be hard to create in a theory-agnostic way hence it might end up being unusable for some resources. at the same time, these are fairly standard requirements to cover phenomena that are found in etymological descriptions provided by a lot of lexicographic resources. however, in a large number of use-cases not all the complexity is warranted: what we are looking for are shallow descriptions of etymologies which are of limited complexity and that lend themselves to fast querying and/or processing. 1 consequently, in the current work, instead of proposing a standard, 'deep' rdf based modelling, we propose the use of strings to model etymologies in a 'shallow' way. in order to help ensure interoperability and to facilitate querying of such strings in sparql, we define a regular language for representing such 'etymological strings', one that is based on textual conventions for the representations of etymologies in lexicographic works as well as in other kinds of literature. the rest of the paper is structured as follows. in section 2 we motivate the use of our approach and provide further details of the kinds of use cases to which we recommend applying this approach. next, in section 3 we give a full description of the regular language which we propose as a solution. afterwards, in section 4 we give the description of a use case with which we illustrate the way we recommend to query data modelled using this kind of language and present a web interface that uses this approach. ## motivation and use cases this work aims to provide a lightweight method of encoding etymological information as string literals. this is particularly useful when (i) the original information is fairly simple; (ii) only a shallow representation of the etymology is required; (iii) a more involved kind of rdf modeling would introduce unnecessary complexity or overhead (and we may not want to e.g., explicitly represent etymologies as hypotheses or model time as a parameter). for instance, in many cases source etymologies will be given in a form similar to the following one for the word friar (example from @xcite ): latin frāter "brother" > old french frère "brother, member of a religious order" > middle english frere, @xmath0. this example gives a description of the history of a word, but etymologies can also describe other linguistic elements, such as senses as in the following case where the semantic development of the english word is given sad (example taken, again, from @xcite ): satisfied, having had one's fill (of something) [metamorphized and narrowed] > weary or tired (of something) [borrowed] > sorrowful, mournful our argument is that in these, and a large number of similar cases, following a more involved rdf modelling (such as that proposed in (khan, 2018)) would create too much overhead in terms of rdf triples, given that most often users are interested only in basic kinds of etymological information or an entry as a whole. indeed, in such simple cases, we could encode the essential information in the form of a string literal allowing users to extract neccessary pieces of information via sparql queries that make use of regular expressions or via the use of simple string matching functions on the results of a sparql query, thus providing complexityon-demand while preserving all the information. an alternative to this approach (that would also avoid the prolixity which we have just mentioned) would be to define an rdf vocabulary, or series of vocabularies, that captured only some of the requirements which we listed above but that e.g., didn't take the explicit representation of time into consideration or that associated only limited kinds of information with different individual stages of an etymology. however, we feel ours is a cleaner alternative, and one that better fits the current trend towards minimal computing (and of course in more complicated kinds of use cases we would suggest using a more extensive ontology based approach). in order to preserve interoperability as far as possible, our idea is to define a simple regular language (i.e., a set of strings that can be described with a regular expression) which our etymological strings must belong to. this regular language is based on the simple string representation used in etymological dictionaries, and example of which we saw above. we describe this language in the following section in ebnf for the purposes of explanation. ## description of the etymological string regular language in the rest of the article we lay out and describe our first proposal for an etymological string language. this language has been designed with the following features: according to this language, our previous friar example can be rewritten as follows: lat @xmath1, @xmath2: durkin) . similarly we can rewrite the sad example above as follows: 'satisfied, having had one's fill (of something)' [metamorphized and narrowed] > 'weary or tired (of something)' [borrowed] > 'sorrowful, mournful' this language is clearly limited in the kinds of etymological information which can be captured. at the same time it fits a large number of simpler cases as found in many lexicographic works. the clear benefit of the formalism is that it provides a middle ground between human-and machine-readability: while still looking familiar to lexicographers and etymologists, it can be validated and processed with efficient and simple computational methods. ## the chamuça test set as a test set for our regular language we decided to use the chamuça hindi language lexicon (chamuça-hi), one of the outputs of an ongoing project, chamuça, which aims to trace the impact of portuguese on the languages of asia @xcite . chamuça-hi consists of just over a hundred entries in hindi, each of which at least plausibly derive from an original portuguese etymon. 3 for many of these entries there are alternative etymologies positing a non-portuguese origin of the entry in question. overall, however, the etymological information included in the dataset is fairly shallow; it is therefore ideal for showcasing our lightweight approach. we had already converted our dataset into rdf @xcite , but decided to generate another version with the addition of etymological strings which follow the regular language proposed in this article, associating the entries with their etymologies using the lexinfo foot_3 etymology property. for instance, see the following entry for the word अन-न्नास (anannaas) meaning 'pineapple': other examples of etymological strings from the dataset include: the question mark at the beginning of each lemma here signals the fact that the etymology is regarded as being doubtful in the source itself. in each of these cases, the creation of an rdf graph explicitly encoding the same etymological information would have meant creating individuals for each of these etymons as well as for the etymology itself with a high cost in the number of resulting triples. encoding the information as strings as we have done in this case, we are still able to extract quite a lot of relevant etymological information either via sparql queries or using basic string processing functions from different programming languages. for instance we can write a simple query which gives the number of alternative entries for each etymology: prefix lexinfo: <http ://www.lexinfo.net/ontology/2.0/ lexinfo#> prefix ontolex: <http ://www.w3.org/ns/lemon/ontolex #> select ?entry ((strlen(str(?etymology)) -strlen(replace( str(?etymology), "\\|", ""))) + 1 as ? numalternatives) where { ?entry a ontolex:lexicalentry ; lexinfo:etymology ?etymology . } another example would be a query which searches of all words which potentially have an ancient greek etymon: prefix lexinfo: <http ://www.lexinfo.net/ontology/2.0/ lexinfo#> prefix ontolex: <http ://www.w3.org/ns/lemon/ontolex #> select ?entry ?etymology where { ?entry a ontolex:lexicalentry ; lexinfo:etymology ?etymology . # grc in the beginning or @xmath3, "(^|>|\\|)\\s * grc\\b") ) } using a combination of queries like this users can extract specific parts of etymologies in which they are interested. an additional advantage of this approach is that the users are not limited to using sparql queries to process the data: while etymological strings has to be extracted with sparql, further processing can be done in a variety of ways, thanks to wide support of regular expressions by software and programming languages. to demonstrate a possible way to use etymological strings in a user-friendly way, we created a web interface that provides basic etymological data for a chosen entry from this dataset. foot_4 ## conclusions and future work in this article we have presented a first draft of our work on etymological strings, a formalised way to represent etymological information in a string, without expanding it to complex graph representations. while unconventional, it is a convenient and efficient way to hide unnecessary data complexity without losing it, all while providing the data in both machine-and human-readable way. in the future we plan to enrich these strings with further kinds of information such as e.g., part of speech and gender. however we feel that the proposed formal language is already suitable for a large number of use cases. however we do not want to make the language or strings too complicated since this would defeat the purpose of using our approach in the first place. also in the future we plan to look into whether our approach is also useful for other kinds of information, i.e., morphological information.