{'fraction_non_alphanumeric': 0.028337819308313444, 'fraction_numerical': 0.0076684779848661825, 'mean_word_length': 5.182731554160125, 'pattern_counts': {'":': 0, '<': 13, '<?xml version=': 0, '>': 13, 'https://': 1, 'lorem ipsum': 0, 'www.': 3, 'xml': 8}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Specifying Conceptual Models Using Restricted Natural Language

The key activity to design an information system is conceptual modelling which brings out and describes the general knowledge that is required to build a system. In this paper we propose a novel approach to conceptual modelling where the domain experts will be able to specify and construct a model using a restricted form of natural language. A restricted natural language is a subset of a natural language that has well-defined computational properties and therefore can be translated unambiguously into a formal notation. We will argue that a restricted natural language is suitable for writing precise and consistent specifications that lead to executable conceptual models. Using a restricted natural language will allow the domain experts to describe a scenario in the terminology of the application domain without the need to formally encode this scenario. The resulting textual specification can then be automatically translated into the language of the desired conceptual modelling framework.


Introduction
It is well-known that the quality of an information system application depends on its design. To guarantee accurateness, adaptability, productivity and clarity, information systems are best specified at the conceptual level using a language with names for individuals, concepts and relations that are easily understandable by domain experts (Bernus et al., 2013). Conceptual modelling is the most important part of requirements engineering and is the first phase towards designing an information system (Olivé, 2007). The conceptual design procedure generally includes data, process and be-havioral perceptions, and the actual database management system (DBMS) that is used to implement the design of the information system (Bernus et al., 2013). The DBMS could be based on any of the available data models. Designing a database means constructing a formal model of the desired application domain which is often called the universe of discourse (UOD). Conceptual modelling involves different parties who sit together and define the UOD. The process of conceptual modelling starts with the collection of necessary information from the domain experts by the knowledge engineers. The knowledge engineers then use traditional modelling techniques to design the system based on the collected information.
To design the database, a clear understanding of the application domain and an unambiguous information representation scheme is necessary. Object role modelling (ORM) (Halpin, 2009) makes the database design process simple by using natural language for verbalization, as well as diagrams which can be populated with suitable examples and by adding the information in terms of simple facts. On the other hand, entity relationship modelling (ERM) (Richard, 1990;Frantiska, 2018) does this by considering the UOD in terms of entities, attributes and relationships. Objectoriented modelling techniques such as the unified modelling language (UML) (O´Regan, 2017) provide a wide variety of functionality for specifying a data model at an implementation level which is suitable for the detailed design of an object oriented system. UML can be used for database design in general because its class diagrams provide a comprehensive entity-relationship notation that can be annotated with database constructs.
Alternatively, a Restricted Natural Language (RNL) (Kuhn, 2014) can be used by the domain experts to specify system requirements for conceptual modelling. A RNL can be defined as a subset of a natural language that is acquired by constraining the grammar and vocabulary in order to reduce or remove its ambiguity and complexity. These RNLs are also known as controlled natural language (CNL) (Schwitter, 2010). RNLs fall into two categories: 1. those that improve the readability for human beings especially for non-native speakers, and 2. those that facilitate the automated translation into a formal target language. The main benefits of an RNL are: they are easy to understand by humans and easy to process by machines. In this paper, we show how an RNL can be used to write a specification for an information system and how this specification can be processed to generate a conceptual diagram. The grammar of our RNL specifies and restricts the form of the input sentences. The language processor translates RNL sentences into a version of description logic. Note that the conceptual modelling process usually starts from scratch and therefore cannot rely on existing data that would make this process immediately suitable for machine learning techniques.

Related Work
There has been a number of works on formalizing conceptual models for verification purposes (Berardi et al., 2005;Calvanese, 2013;Lutz, 2002). This verification process includes consistency and redundancy checking. These approaches first represent the domain of interest as a conceptual model and then formalize the conceptual model using a formal language. The formal representation can be used to reason about the domain of interest during the design phase and can also be used to extract information at run time through query answering.
Traditional conceptual modelling diagrams such as entity relationship diagrams and unified modelling language diagrams are easy to generate and easily understandable for the knowledge engineers. These modelling techniques are well established. The problems with these conventional modelling approaches are: they have no precise semantics and no verification support; they are not machine comprehensible and as a consequence automated reasoning on the conceptual diagrams is not possible. Previous approaches used logic to formally represent the diagrams and to overcome these problems. The description logic (DL) ALCQI is well suited to do reasoning with entity relationship diagrams (Lutz, 2002), UML class diagrams (Berardi et al., 2005) and ORM diagrams . The DL ALCQI is an extension of the basic propositionally closed description logic AL and includes complex concept negation, qualified number restriction, and inverse role. Table 1 shows the constructs of the ALCQI description logic with suitable examples. It is reported that finite model reasoning with AL-CQI is decidable and ExpTime-complete 1 . Using logic to formally represent the conceptual diagrams introduces some problems too. For example, it is difficult to generate logical representations, in particular for domain experts; it is also difficult for them to understand these representations and no well established methodologies are available to represent the conceptual models formally. A solution to these problems is to use a RNL for the specification of conceptual models. There exist several ontology editing and authoring tools such as AceWiki (Kuhn, 2008), CLOnE (Funk et al., 2007), RoundTrip Ontology Authoring (Davis et al., 2008), Rabbit (Denaux et al., 2009), Owl Simplified English (Power, 2012) that already use RNL for the specification of ontologies; they translate a specification into a formal notation. There are also works on mapping formal notation into conceptual models (Brockmans et al., 2004;Bagui, 2009).

Proposed Approach
Several approaches have been proposed to use logic with conventional modelling techniques to verify the models and to get the semantics of the domains. These approaches allow machines to understand the models and thus support automated reasoning. To overcome the disadvantages associated with these approaches, we propose to use an RNL as a language for specifying conceptual models. The benefits of an RNL are: 1. the language is easy to write and understand for domain experts as it is a subset of a natural language, 2. the language gets its semantics via translation into a formal notation, and 3. the resulting formal notation can be used further to generate conceptual models.
Unlike previous approaches, we propose to write a specification of the conceptual model in RNL first and then translate this specification into description logic. Existing description logic rea-

Syntax
Example soners 2,3 can be used to check the consistency of the formal notation and after that desired conceptual models can be generated from this notation. Our approach is to derive the conceptual model from the specification whereas in conventional approaches knowledge engineers first draw the model and then use programs to translate the model into a formal notation (Fillottrani et al., 2012). Figure 1 shows the proposed system architecture for conceptual modelling.

Scenario
Let's consider an example scenario of a learning management system for a university stated below: A Learning Management System (LMS) keeps track of the units the students do during their undergraduate or graduate studies at a particular university. The university offers a number of programs and each program consists of a number of units. Each program has a program name and a program id. Each unit has a unit code and a unit name. A student can take a number of units whereas a unit has a number of students. A student must study at least one unit and at most four units. Every student can enrol into exactly one program. The system stores a student id and a student name for each student.
We reconstruct this scenario in RNL and after that the language processor translates the RNL specification into description logic using a featurebased phrase structure grammar (Bird et al., 2009). Our RNL consists of function words and content words. Function words (e.g., determiners, quantifiers and operators) describe the structure of the 2 https://franz.com/agraph/racer/ 3 http://www.hermit-reasoner.com/ RNL and their number is fixed. Content words (e.g, nouns and verbs) are domain specific and can be added to the lexicon during the writing process. The reconstruction process of this scenario in RNL is supported by a look-ahead text editor (Guy and Schwitter, 2017). The reconstructed scenario in RNL looks as follows: (a) No student is a unit.
(c) Every student is enrolled in exactly one program.
(d) Every student studies at least one unit and at most four units.
(e) Every student has a student id and has a student name.
(f) No program is a unit and is a student.
(g) Every program is composed of a unit.
(h) Every program is enrolled by a student.
(i) Every program has a program id and has a program name.
(j) No unit is a student and is a program.
(k) Every unit is studied by a student.
(l) Every unit belongs to a program.
(m) Every unit has a unit code and has a unit name.
Additionally, we use the following terminological statements expressed in RNL: (n) The verb studies is the inverse of the verb studied by. (o) The verb composed of is the inverse of the verb belongs to.

Grammar
A feature-based phrase structure grammar has been built using the NLTK (Loper and Bird, 2002) toolkit to parse the above-mentioned specification. The resulting parse trees for these sentences are then translated by the language processor into their equivalent description logic statements. Below we show a scaffolding of the grammar rules with feature structures that we used for our case study: In order to translate the resulting syntax trees into the description logic representation, we have used the owl/xml syntax 4 of Web Ontology Language (OWL) as the formal target notation.

Case Study
The translation process starts by reconstructing the specification in RNL that follows the rules of the feature based grammar. While writing the specification in RNL, we tried to use the same vocabulary as in the natural language description.
The first two sentences of our specification use a negative quantifier in subject position and an indefinite determiner in object position: (a) No student is a unit.
(b) No student is a program.
(d) Every student studies at least one unit and at most four units.
(h) The verb composed of is the inverse of the verb belongs to.
The translation of these two sentences results in the specification of inverse object properties. The translation of sentence (g) leads to the object properties study and studied by which are inverse object properties. Similarly, the translation of sentence (h) states that the object properties composed of and belong to are also inverse object properties. These statements correspond to the inverse role construct in the DL ALCQI. <InverseObjectProperties> <ObjectProperty IRI="#study"/> <ObjectProperty IRI="#studied_by"/> </InverseObjectProperties> <InverseObjectProperties> <ObjectProperty IRI="#composed_of"/> <ObjectProperty IRI="#belong_to"/> </InverseObjectProperties> The rest of the specification is similar to the examples that we have discussed above.

Reasoning
After generating the owl/xml notation for the RNL specification, we use Owlready (Lamy, 2017) that includes the description logic reasoner Her-miT (Glimm et al., 2014) for consistency checking. Owlready is a Python library for ontologyoriented programming that allows to load OWL 2.0 ontologies and performs various reasoning tasks. For example, consistency checking of the specification can be performed on the class level. If a domain expert writes for example "No student is a unit" and later specifies that "Every unit is a student", then the reasoner can detect this inconsistency and informs the domain expert about this conflict. The owl/xml notation below shows how this inconsistency ("owl:Nothing") is reported after running the reasoner. <rdf:Description rdf:about="http://www.w3.org/2002/07/owl#Nothing"> <owl:equivalentClass rdf:resource= "http://www.w3.org/2002/07/owl#Nothing"/> <owl:equivalentClass rdf:resource="#student"/> <owl:equivalentClass rdf:resource="#unit"/> </rdf:Description> This inconsistency can be highlighted directly in the RNL specification; that means the domain expert can fix the textual specification and does not have to worry about the underlying formal notation.

Conceptual Model Generation
In the next step, we extract necessary information such as a list of entities (classes), attributes (data properties) and relationships (object properties) from the owl/xml file to generate the conceptual model. This information is extracted by executing XPath (Berglund et al., 2003) 5 queries over the owl/xml notation and then it is used to build a database schema containing a number of tables representing the entities with associated attributes. Relationships among the entities are represented by using foreign keys in the tables. An SQL script is generated containing SQLite commands 6 for this database schema.
This SQL script is executed by using SQLite to generate the corresponding database for the specification. After that, we use SchemaCrawler 7 to generate the entity relationship diagram (see fig.  2) from the SQL script. SchemaCrawler is a free database schema discovery and comprehension tool that allows to generate diagrams from SQL code.
For mapping a description logic representation to an entity relationship diagram, we have used the approach described by Algorithm 1. All the classes in the OWL file become entities in the ERdiagram. Object properties are mapped into relations between the entities and data properties are mapped into attributes for these entities. The qualified cardinality restrictions of the object properties define relationship cardinalities in the diagram.
We understand conceptual modelling as a round tripping process. That means a domain expert can Algorithm 1: Mapping description logic representation to SQLite commands for generating entity relationship diagrams.
Input: Logical notation in description logic Output: SQLite script entity list= extract class(owl/xml file); data property list= extract data property(owl/xml file); object property list= extract object property(owl/xml file); for enity in entity list do create table(entity) for data property in data property list do add data property(entity, data property) for object property in object property list do if cardinality == 1 then add data property(entity, data property) end end end for object property in object property list do create relationship(entity, object property) end end write the RNL specification first, then generate the conceptual model from the specification, and then a knowledge engineer might want to modify the conceptual model. These modifications will then be reflected on the level of the RNL by verbalising the formal notation. During this modification process the reasoner can be used to identify inconsistencies found in a given specification and to give appropriate feedback to the knowledge engineer on the graphical level or to the domain expert on the textual level.

Discussion
The outcome of our experiment justifies the proposed approach for conceptual modelling. We have used a phase structure grammar to convert a RNL specification into description logic. This experiment shows that it is possible to generate formal representations from RNL specifications and these formal representations can be mapped to different conceptual models. The proposed approach for conceptual modelling addresses two research challenges 8 : 1. providing the right set of modelling constructs at the right level of abstraction to enable successful communication among the stakeholders (i.e. domain experts, knowledge engineers, and application programmers); 2. preserving the ease of communication and enabling the generation of a database schema which is a part of the application software.

Future Work
We are planning to develop a fully-fledged restricted natural language for conceptual modelling of information systems. We want to use this language as a specification language that will help the domain experts to write the system requirements precisely. We are also planning to develop a conceptual modelling framework that will allow users to write specifications in RNL and will generate conceptual models from the specification. This tool will also facilitate the verbalization of the conceptual models and allow users to manipulate the models in a round tripping fashion (from specification to conceptual models and conceptual models to specifications). This approach has several advantages for the conceptual modelling process: Firstly, it will use a common formal representation to generate different conceptual models. Secondly, it will make the conceptual modelling process easy to understand by providing a framework to write specifications, generate visualizations, and verbalizations. Thirdly, it is machineprocessable like other logical approaches and support verification; furthermore, verbalization will facilitate better understanding of the modelling process which is only available in limited forms in the current conceptual modelling frameworks.

Conclusion
In this paper we demonstrated that an RNL can serve as a high-level specification language for conceptual modelling, in particular for specifying entity-relationship models. We described an experiment that shows how we can support the proposed modelling approach. We translated a specification of a conceptual model written in RNL into an executable description logic program that is used to generate the entity-relationship model. Our RNL is supported by automatic consistency checking, and is therefore very suitable for formalizing and verifying conceptual models. The presented approach is not limited to a particular modeling framework and can be used apart from entity-relationship models also for object-oriented models and object role models. Our approach has the potential to bridge the gap between a seemingly informal specification and a formal representation in the domain of conceptual modelling.