Lexon Engineering

(Note: The work is a part of PRIME project deliverables written by Tang, Y and Spyns, P during 2004 till 2006)

We group under this heading these activities that transform the domain conceptualisation that, under the form of verbalised facts in natural language, is still independent of any ontology language or representation formalism. In the following steps, the informal conceptualisation is progressively transformed into formal statements, fitting the VUB DOGMA ontology engineering formal framework. Nevertheless, in our opinion these steps are also useful when implementing an ontology in RDF or OWL. RDF or OWL Lite statements could be a direct result of the lexon engineering stage as the format of the lexons is very close to RDF or OWL Lite statements. As OWL DL statements contain semantic constraints, we have to finish the application specification step before being able to produce OWL DL statements。

This stage consists of the formalisation of the verbalised facts followed by quality control checks. The terms and roles of the remaining lexons are linked to unambiguous definitions.

1.1.1.1.1 Create lexons

This activity uses the verbalised facts resulting from the previous step as input. The aim is to extract lexons. The results are represented as binary fact types or lexons in the form <γ, t_i, r_i-j, r_j-i, t_j> where the terms t_i and t_j refer to concepts and the roles r_i-j and r_j-i refer to the relationships by which these are related. Currently, the context γ refers to the particular section or input document from which the lexon has been extracted[1]. If the results of the previous activities are binary in nature (as stressed in previous sections), this exercise is significantly simplified.

Table 2‑13 Privacy Directive Lexon Table[2]

1.1.1.1.2 Refine lexons

The lexons newly created should undergo a kind of quality check. We say that a lexon is a ‘good’ one when

• This lexon is highly reusable
• This lexon is as simple as possible
• This lexon represents the correct information
• This lexon cannot be broken down any more

Note that the creation of elementary sentences should almost automatically lead to good lexons. Nevertheless, it could happen that some elementary sentences are to be represented by more than one lexon and vice verse. It mostly concerns knowledge implied (but not explicitly mentioned) by an elementary sentence.

Table 2‑14 shows an example based on the material from Table 2‑13.
Table 2‑14 Lexon refinement example

A term or role (or sometimes an expression) used in a specific context and language in principle points to a non ambiguous meaning. It can happen that equal or synonymous lexons or triples have been produced in the course of the domain conceptualisation and lexon engineering steps.

As it is senseless to keep such lexons (also possibly across language borders), the synonymous or equal cases are deleted in this activity. A refined lexon are voted to represent all the literally equal lexons (all composing words are the same) and synonymous lexons (the composing words are the same or synonymous). Two lexons or triples are equal when the respective terms and roles point to the same concepts (as have been defined in the previous step). This also holds when the sequence of terms and roles is inversed. In case of an inversed sequence, words can be antonyms.

Let’s look at three examples:

1. <bike, follow, be followed by, car> & <bicycle, go after, be followed by, automobile>

This example illustrates that two lexons are synonymous when their composing parts have the same sense. Here, bike is bicycle, follow is to go after, and a car is an automobile.

2. <dog, eat, be eaten, meat> & <meat, be eaten, eat, dog>

This sample illustrates that two lexons are equal when their terms and roles are equal (possibly in inverse sequence).

3. <bike, follow, be followed, car> & <automobile, precede, is preceded by, bicycle>

This example is the combination of two previous examples. The terms are synonyms and inversed while the role names are antonyms.

Simple sorting tools (e.g., ‘sort’, ‘unique’ Linux shell commands or spreadsheet functionalites) can already provide a basic level of automation. More sophistication can be achieved by implementing calls to on-line dictionaries, using the WordNet API, or e.g., using the DOGMA concept server[3] functionalities for checking on synonymy/antonymy.

As the core of this and the previous activities concerns the definition of meaning and linking the lexical representations to concepts, it is of primary importance that a sufficient number of stakeholders are gathered so that the refined lexons are based on widely accepted agreements.

In the case of the DOGMA engineering framework, the software allows to recreate[4] the lexons. Therefore, it is no longer necessary to store the lexons separately. However, for reasons of traceability and quality checks afterwards, it might be worthwhile to store the original lexons anyhow.

Here is an example from the E-Health NS - Table 2‑7:

From the NS note, we can extract one lexon as: <NSID:1_note, patient, choose, isChosen, GP>. And from the Narratological Schema episode E1.1.2, another lexon is extracted as: <Narratological SchemaID:1 E1.1.2, user, choose, isChosen, GP>. We might recognize that those two lexons are equal because the user here means the patient[5].

1.1.1.1.3 Ground lexons

Lexon grounding is a conceptual exercise that links the terms and roles that constitute a lexon to existing dictionaries, lexica or standards. If no adequate definitions exist, then new definitions should be drafted by hand following terminological principles by the domain experts and other stakeholders. In this way the vocabulary of the ontology (in the form of terms and roles) is provided with semantics. As a result, synonyms are easily detectable (i.e. they point to the same definition). As a check or additional source, the list of synonyms created by using Abstraction mechanism (see section 2.2.5.2.2), if available, can be used. New labels have to be chosen for a set of synonyms or expressions having the same meaning. These labels are preferably (slightly) different from natural language words to indicate that they operate on the conceptual level rather than the language level. In the VUB DOGMA ontology engineering framework, the definitions, the labels and the synonyms are entered in the concept definition server. Other implementations offering a similar functionality can be envisaged.

The same example is continued:

Table 2‑15 Lexon Dictionary

The following table shows several lexons extracted from Table 2‑11.

Table 2‑16 Settings of E-Health Narratological Schema

Table 2‑17 Lexon Table of E-Health Settings