FactEngine Knowledge Language (FEKL)
Enabling the Semantic Layer with Natural Language Business Rules
FactEngine Knowledge Language (FEKL) is a controlled natural language to define Fact-Based Models, enabling what FactEngine calls a Semantic View over a Semantic Layer.
Business Rule definition and Enterprise Conceptual Modelling is made easy with FEKL where business rules are defined in natural language.
In brief, FEKL produces or documents the semantic information of your organisation and as captured by knowledge graphs, and/or graph/relational database, as in your Data Warehouse or Data Lake, and as expressed in your Semantic Layer.
ER-Diagrams, Property Graph Schema and Object Role Models may be generated automatically from FEKL statements.
Business rules in natural language reflect a human need to easily comprehend and form their own conceptual model of the businesses they work in. If, at the same time, those business rules reflect the database they operate over, we have the making of a semantic view. A semantic view maybe over one database, multiple databases, a data lake or a data warehouse. A glossary of the business knowledge stored for business intelligence purposes.
Non-technical people are not necessarily interested in the technical terms used in conceptual modelling. But at the same time, business users and business analysts require business information to be able to perform their roles within organisations. The same problem exists for technical people also, with a wide variety of conceptual modelling languages available, for which they may not be proficient, and/or a database of knowledge so vast in its breadth of coverage that it easier to conceive of, and learn from, a data catalogue or data dictionary expressed as business rules in natural language.
It is only happenstance that the world is moving towards the predominant use of natural language when it comes to knowledge, as in the Large Language Models used for artificial intelligence, as it was always going to be that way, natural language the predominant form of message exchange between people even where business and non-verbal cues are available.
FactEngine Knowledge Language maps directly to a natural language-based type of conceptual modelling called, Object-Role Modelling (ORM), and stems from work originally produced by Clifford Heath, a research scientist who first took the natural language component view of ORM and effectively said, “We can model our whole database in controlled natural language”, controlled natural language forming a full half the syntax of Object-Role Modelling.
With FEKL, you have a choice.
You can learn the syntax, without knowing the technical terms, or you can learn a very few technical terms and understand what it is you are looking at, in the same way that all people have a concept of a concept, and object type and constraints, as in a business constraint that expresses that each car rental has one rental contract.
Only Value Types, Entity Types, Fact Types and Constraints are needed to express a database schema in natural language.
We can even use FEKL to produce/define example data for tables/nodes in a database so that people can get to know a database and the data they look over. For instance, Car Rental, 948, has Rental Contract, 237, may be a valid fact within our FEKL expression of a business domain, and where natural language meets data.
The following are valid FEKL statements:
There are many reasons why you may prefer to create a conceptual model using natural language rather than drawing diagrams. These include:
- Capturing the business rules of your enterprise conceptual model;
- Automatically generating model definition based on NLP (Natural Langue Processing) of a corpus of documents;
- It can be quicker to create diagrams using natural language, rather than using a GUI (Graphical User Interface), depending on your proficiency with FEKL; and
- Business Analysts can capture the Universe-of-Discourse, or the business domain knowledge, in natural language. I.e. Analysts use FEKL as a tool to capture business requirements.
FEKL — Core Concepts and Precedent Order
If we perceive of the words used to capture concepts as model elements within our conceptual model of the business domain, then we can form a view as to how a model is built and shared as knowledge.
The precedent order of model element creation, for the model, is:
- Value Types (unless created at the time of defining an Entity Type’s Reference Mode, or as part of the definition of a Binary Fact Type).
Value Types range over a set of values. E.g. “Company Name”; - Entity Types, such as “Company”, equate to the Entities of ER-Diagrams for relational databases, or Node Types of Property Graph Schema for graph databases;
- Fact Types, which define the Facts stored by a database.
E.g. Company has Company Name is a Fact Type,
Business, 354, has Business Name, ‘FactEngine’, is a Fact; - (Role) Constraints (unless an Internal Uniqueness Constraint created at the time of Fact Type creation), which constrain values within Facts.
Object Types and their Naming Convention — FEKL
Entity Types and Value Types are called Object Types in FEKL. And so are a special type of Fact Type, called an Objectified Fact Type, which we are all familiar with, as in “Stocked Item IS WHERE Part is in Bin in Warehouse”. The Fact Type (Reading) is “Part is in Bin in Warehouse”, Stocked Item, is the Object Type.
Use of Pascal Case
Object Type names in FEKL are written in Pascal Case (with spaces), with each word/acronym in the Object Type’s name having a starting capital letter. Pascal Case is where the first letter of each word starts with a capital.
E.g. Power Source
Value Type creation — FEKL
The following are examples of Value Type creation statements written in FEKL:
I.e. Where ‘Company Name’ is the Value Type being created, and StringFixedLength(100) defines the Data Type applicable to the Value Type.
Value Types can also be created when creating a Fact Type for pre-existing model elements, for example:
I.e. Where ‘Company Name’ is a Value Type and ‘Company’ is an Entity Type or Objectified Fact Type.
Value Types can also be created automatically when defining the Reference Mode for a Value Type. For example, the Value Type, ‘Company_Id’ is automatically created in the model when the Reference Mode for the ‘Company’ Entity Type is defined in the following statement:
Data Types in FEKL
The Data Types in FEKL are based on the Data Types available for Value Types in the Boston conceptual modelling software, however if you document your Semantic Layer with different data types, use its data types.
NB Value Types in Object-Role Modeling software require Data Types such that the corresponding Column/Attribute/Property/Field within the respective Entity-Relationship Diagram and Property Graph Schema have a Data Type that is commensurate with the Data Type of the corresponding Column/Attribute/Property/Field within any underlying/connected database.
NB Some Data Types require either a Length or a Precision to be specified.
E.g. Data Type with Length:
E.g. Data Type with Precision:
Entity Type creation in FEKL
The following are examples of Entity Type creation statements written in FEKL:
I.e. Where ‘Company’ is the name of the Entity Type and where ‘Id’ is the Reference Model of the Company Entity Type.
NB The resultant Reference Model for the Entity Type in Boston for the ‘Company’ Entity Type will be ‘.Id’ and the resultant Value Type for the Reference Scheme will be ‘Company_Id’.
NB A Reference Mode for an Entity Type can be created after the Entity Type has already been created. I.e. No error is returned if the Entity Type already exists in the model when using the following statement:
Fact Type creation in FEKL
Binary Fact Type creation:
N-Ary Fact Type creation:
NB The ‘IS WHERE’ statement above defines the name of the Fact Type, ‘Stocked Item’ and two Fact Type Readings for the ternary Fact Type, ‘Part is in Bin in Warehouse’ and ‘Warehouse houses Part in Bin’.
Cardinality of Fact Types
When Fact Types are defined, the cardinality of the relationship between Object Types can be defined at the same time. Examples below.
The ONE clause in FEKL is used to create a Fact Type with a Mandatory Role Constraint and Internal Uniqueness Constraint.
E.g. The following FEKL statement with a ONE clause creates the Object-Role Model below that.
FEKL:
Object-Role Model:
NB At this stage the Person Entity Type has no Reference Mode and so is in error and coloured red in an Object-Role Modeling tool such as Boston, and similarly the Name Value Type has no Data Type, and so is in error and is red.
The AT MOST ONE clause in FEKL is used to create a Fact Type an Internal Uniqueness Constraint but without a Mandatory Role Constraint.
Optionally, if the second Object Type is a Value Type, the Data Type of the Value Type can be defined.
E.g. The following FEKL statement with a AT MOST ONE clause creates the Object-Role Model below:
FEKL:
Object-Role Model:
NB At this stage the Person Entity Type has no Reference Mode and so is in error and coloured red, and similarly the Name Value Type has no Data Type, and so is in error and is red.
OPTIONALLY DEFINING THE DATA TYPE OF A VALUE TYPE
FEKL:
Object-Role Model:
NB At this stage the Person Entity Type has no Reference Mode and so is in error and coloured red, however the Name Value Type is not in error because we have defined the Data Type for the Value Type, and so is not red, but blue.
The AT LEAST ONE clause in FEKL is used to create a Fact Type with a Mandatory Role Constraint and an Internal Uniqueness Constraint on the far Role of the Fact Type.
E.g. The following FEKL statement with a ONE clause creates the Object-Role Model below:
FEKL:
Object-Role Model:
NB If a Many-to-Many Relationship is required, rather than a 1-to-Many Relationship, the Internal Uniqueness Constraint on the Fact Type can be changed. E.g. If you need the relationship to be reciprocal and where a Management Role can also have many Managers.
NB At this stage the Manager Entity Type has no Reference Mode and so is in error and coloured red, and similarly the Management Role Value Type has no Data Type, and so is in error and is red.
— — —
© Victor Morgante and FactEngine.
===================End===================
