In this article we discuss the conversion of a legacy lexical resource, an abridged version of the ancient Greek-English lexicon, the Liddell-Scott-Jones lexicon, into RDF using the lemon model discussing some of the challenges we confronted during this conversion. We will also introduce the polyLemon vocabulary which we introduced to describe the structuring of the senses in a lexical entry in a dictionary.
salient structural information already marked out and annotated, in this case
TEI, had already been done for us by the Perseus project2. That is, we were able
to take advantage of the fact Perseus project had already made the ML available
with an open license, along with an abundant amount of other language resources
{ and not only in Greek and Latin but also in a number of other languages such
as Icelandic and Arabic. Indeed in the near future we are planning to convert and
publish some of these other Perseus lexica as LOD too, including the full version
of the Liddell-Scott-Jones (LSJ) lexicon [
One of the most important aspects of the publication of datasets in RDF is the use and re-use of models/vocabularies which allow the explicit encoding of pertinent aspects of the dataset to be modelled. Indeed the re-use of models, standards and vocabularies, is one of the core best practices underpinning the linked open data publishing paradigm. This means in e ect that anyone who wants to publish data as linked open data is strongly encouraged, in the interests of interoperability, to check for the availability of already existing vocabularies which ful l the modelling requirements of the dataset in question.
Perhaps the single most popular model for modelling and representation of
lexical datasets as RDF is the lemon model (LExicon MOdel for ONtologies) [
One important factor to take into consideration here is that lemon was
originally proposed as a model for helping enrich ontologies with linguistic
information and not for converting data arising from already existing lexicographic
resources and that conforms to certain conventions of printed dictionaries [
in the form of an OWL axiom. In many print dictionaries however the senses of a single entry may be nested in order to give a more complex description of the meaning of a word, and often it doesnt seem necessary or even viable for each individual sense listed in a dictionary to be linked to its own separate concept. And so it's important to be able to represent this and other structural aspects of the original data. In what follows we will look at the additional classes and properties that we have de ned and that fall outside the scope of those already included in the Ontolex-Lemon speci cations.
Although we cannot go into much depth in this article on the di erent approaches to representing print dictionaries using a computational model like RDF or LMF, and in particular how faithful to be in representing di erent aspects of the organisation of the original resource, we will nevertheless touch on these and related issues in what follows. 3
In the course of carrying out background research on traditional lexicographic resources, we found that the complex nested structure that one sees in the ML was actually very common in other scholarly or comprehensive print dictionaries such as the Lewis-Short Latin-English lexicon and the Oxford English Dictionary. Within the TEI-DICT guidelines this nesting is captured by the use of the @level attribute of the sense element. For instance take the entry from the ML given in Fig. 1, where the di erent levels of nesting are labeled using Roman and Arabic numerals3. The convention, in the ML, as well as in the original Liddell-Scott-Jones lexicon and in a number of other similar dictionaries, is to label these levels using both Roman and Arabic numerals as well as capital Roman alphabet letters and small Roman alphabet letters, depending on the level of nesting.
As Fig. 1 show the senses in the ML area e ectively organised in a tree structure. The Perseus TEI-DICT XML version of this entry is shown in Fig. 2. When it came to representing this sense tree structure in RDF, and given that however we decided to create an extension of the lemon core model, called polyLemon4.
PolyLemon consists of the object properties senseSibling, senseChild and senseDescendant and the datatype properties senseLevel and senseID all of which help to determine the position of a sense in the sense tree of a lexical entry.
Figure 5 represents, in diagrammatic form, the polyLemon based RDF encoding of the sense structure of the ML entry given in Figs. 1 and 2. The horizontal arrows represent instances of the senseSibling property and the vertical/slanted lines instances the senseChild property. 3 This entry can be accessed via the Perseus Hopper here http://www.perseus.tufts.
edu/hopper/. 4 http:\\lari-datasets.ilc.cnr.it/polyLemon
It is important to note here that, as Lew argues in [
However we felt in the end that this was to be take too puritanical an approach and that in the interests of interoperability and the accessibility of the resource given the popularity and widespread use of lemon { we would stick to the lemon:LexicalSense class using polyLemon to describe the senses of each entry in order to specify the fact that we were dealing with a speci c type of arrangement to be found mostly in dictionaries. Alternatively the possibility was suggested to us of rede ning dictionary senses as skos:Concept entities and therefore circumventing the use of polyLemon to de ne a hierarchical sense structure. Note that entities of the type skos:Concept are de ned as being independent of the terms used to de ne them5, but lexicographic senses, as we might call them, even if they di er from other kinds of word senses, still, arguably, serve to describe the use of words when used with a certain meaning within a certain language community and do not directly describe the referent or conceptual content itself { at least not independently of the lexical entry is associated with the sense (the Lexical Concept class in ontolex is a subclass of
skos:Concept and so faces the same di culties as the latter in this regard). On the other hand it is true that senses in ML are often used to group together more speci c senses, a situation { something that could be modeled using skos relations narrower and broader { although, as we mentioned above, in the case of the ML and many other dictionaries this grouping of senses is primarily intended as means of enabling easy access to senses and not as a robust hierarchical conceptualisation of some domain. And so we decided to err on the side of caution and to not make ML dictionary senses skos:Concept entities as we felt that this would have introduced an extra layer of interpretation. In addition we felt that as this hierarchical way of arranging word senses was common enough in traditional lexicographic resources a specialised vocabulary like polyLemon was merited in this case.
Having made the decision to use polyLemon to represent the sense structure of each entry we wrote a script to extract this structure from each lexical entry in the Perseus XML encoding. The rest of the conversion was fairly straightforward. Each lexical entry in our lemon encoding of the ML has both a betacode and a unicode written representation, as well as (when it is explicitly stated in the original Perseus XML dataset) information on part of speech. We used the lexinfo vocabulary to represent this POS data, using the property lexinfo:partOfSpeech and the lexical categories available in lexinfo. We used the IDs used to identify lexical entries and senses in the original Perseus version in our lemon version.
As an example see Fig 4 the lexical entry for dolichos meaning 'race'6. Luckily, most of the information that we wanted to include for each Lexical Sense object in the RDF encoding of the ML, was already marked up within text contents of the sense elements in the Perseus TEI-DICT version of the ML. For instance we can extract a gloss from the text content of each sense element. In our RDF encoding we provide this gloss as a string stripped of all the XML tags present in the original using an adhoc property strippedForm that we have de ned for this purpose. This enables users of our resource to peruse the text of the original entry. 6 Note that the lsj-lemon namespace contains a number of classes and properties which we considered to be useful both for the encoding the Middle Liddell and the original LSJ and which we therefore put into a separate le.
One of the elements that is marked up within the text content of sense elements in the Perseus XML source is the translation of a sense. This is marked up using trans and tr elements. We therefore extracted the translation as a string and linked it to the relevant lemon:LexicalSense object used the lexinfo:translation property. In future we plan to link each sense to an appropriate Wordnet synset.
We made a decision at the start to work on the Middle Liddell as opposed to the full unabridged version of the text, in large part because this made it easier to manually check the resulting conversion of the dictionary. However Perseus have also made a TEI-DICT XML version of the full Liddell Scott Jones dictionary available and provided CTS-URNs for the citations given for each sense; we are also planning to convert this full version in the future. And although this kind of information wasnt encoded in the ML 7, what was included was the name of an author or a corpus in which the sense in question could be located; this is included between the usg tags in the Perseus ML. In most cases it was fairly easy to map between the content of these usg elements since in many cases this information was included either in the printed version of the ML or on the Perseus website { in others we weren't able to nd a relevant DBpedia link. In the current version we have manually linked word senses to DBpedia resource based on what is contained in the usg tags, for instance Aesch. would be mapped to http://dbpedia.org/resource/Aeschylus.
We end this section with an example of the representation of the sense. We take one of the senses of the word ephiemi. The dataset can be accesssed directly at http://lari-datasets.ilc.cnr.it/lsj. We are currently developing a SPARQL interface and setting up a pubby interface. A rst version of both can be found at http://lari-lsj.ilc.cnr.it/LSJSPARQLinterface and http://lari-lsj.ilc.cnr.it/page, respectively. 4
As mentioned above we plan to convert the whole of the Liddell-Scott-Jones lexicon along with the Lewis-Short Latin-English lexicon. We are also working on improving our interfaces in order to make the lexicon accessible to as many researchers as possible, including humanists as well as more technically skilled users. 7 The printed version of the ML doesn't give precise citations for textual attestations.