# A Knowledge Engineering Primer111This primer can freely be used, shared and
adapted under the terms of Creative Commons CC BY 4.0 license.

Agnieszka Ławrynowicz
Poznan University of Technology, Poland

(March 2024)

_The aim of this primer is to introduce the subject of knowledge engineering
in a concise but synthetic way to develop the reader’s intuition about the
area._

##  1 Introduction

Knowledge can take different forms. We distinguish between declarative
knowledge (knowing something) or procedural knowledge (knowing how, know-how),
sensorimotor knowledge (riding a bicycle), and affective knowledge (deep
understanding). The classic definition of _knowledge_ derived from philosophy
defines knowledge as a justified true belief. It can be said to occur in
situations where we consider something to be objectively “true” or “stated”.
Another definition refers to what is “explicit knowledge” that is known and
can be written down [32].

_Knowledge representation_ [11] is a (symbolic) encoding of statements (or
facts) that an agent (human or computer program) recognizes as true. A mapping
can be defined between the facts and their representation, assigning to the
facts the corresponding symbols in the representation. Knowledge
representation in artificial intelligence refers to how data, information, and
knowledge are stored and processed in computer systems.

A _knowledge base, $KB$_ is, in some simplification, a collection of facts
representing entities, classes, attributes, and relationships, relevant
generally or in a particular domain, which is prepared in a digital form. The
above definition of a knowledge base may resemble a database description. How,
then, does a knowledge base differ from a database? A good knowledge
representation system, with which we represent a given knowledge base, on top
of the ability to represent the required forms of knowledge, should ensure the
power and efficiency of reasoning and knowledge extraction. To perform
inference, a type of software called a _reasoner_ is used to derive new facts
from a set of already existing, explicitly represented facts or axioms.

It is worth noting the trade-off between the expressivity of the knowledge
representation language (that is, the variety and number of possibilities for
representing knowledge in it) and the performance of reasoning engines. The
more complex the language, and thus the more diverse forms of modelled
knowledge, the more complex the inference algorithms and the longer the
inference time. In [10], Blumauer and Nagy classified popular knowledge
organization systems. We extend this classification in Table 1 by additional
forms of knowledge representation, showing selected classes of such systems of
increasing complexity.

Table 1: Knowledge organization systems. Knowledge organization system |  Building blocks |  Examples
---|---|---
Thesaurus |  Synonyms, antonyms, broader and narrower concepts, associative relationships |  blueberry = bilberry cold $\neq$ warm Blueberry juice _is related to_ blueberry
Taxonomy |  Hierarchical relationships |  Blueberry is-a fruit
Semantic network |  Any unary and binary relations |  Maria Skłodowska-Curie was born in the year 1867 Parsley root is part of parsley
Frame |  Attributes inherited by subclasses and instances |  Country has a capital. Poland has a capital Warsaw
Ontology |  Classes, attributes, relationships, constraints |  Parsley is a subclass of the class plants Carrot has colour orange Blueberry juice is made from blueberry Every tree has at least one root
Knowledge graph |  Classes, attributes, relationships, constraints, links to other knowledge bases |  Entity Maria_Sklodowska_Curie is the same as entity wikidata:Q7186

Issues of _knowledge acquisition_ , including issues of the knowledge base
construction process, are dealt with by the field of _knowledge engineering_.
A knowledge engineer explores a domain, determines which concepts are relevant
to that domain, and creates a formal representation of entities,
relationships, and constraints for that domain. Although he or she is often
not a domain expert, the role of the knowledge engineer is to obtain knowledge
from domain experts, among other sources.

Most knowledge representation systems proposed in artificial intelligence
research are systems where knowledge is represented in symbolic form and
easily readable by humans. The most important of these are:

  * •

production rules [14],

  * •

semantic networks [34],

  * •

frames [29],

  * •

ontologies [17, 18],

  * •

knowledge graphs [21].

Most modern knowledge representation languages are declarative based on the
concept of frames or first-order logic (predicate calculus) [31, 26, 27].
Establishing a given language on the foundations of logic allows for the
formalization and standardization of reasoning procedures, which in turn
allows for constructing reasoning engines that operate on a given formalism.
It is also worth mentioning that while knowledge structures, such as knowledge
graphs, are currently represented in symbolic form in order to operate on
them, sub-symbolic representations are often created, such as _embeddings_.

Why is the issue of representation important at all? What makes one
representation better than another in the context of artificial intelligence?
Many information and knowledge processing tasks can be very easy or complex,
depending on how they are represented. This general principle applies both in
everyday life and artificial intelligence. To illustrate it, let us take maps
as an example. Old maps, such as those from the 16th century, were static, and
their localities were marked as points rather than regions (polygons). The
digital version of such maps, while continuing to mark localities as points,
allows queries to be made to a historical-geographical information system
about the location and attributes of localities over time and faster
information retrieval. Modern digital maps also have layers (buildings, roads,
forests, etc.) and allow querying on various aspects of the terrain, such as
Points of Interest etc. Depending on the representation and its expressivity,
we can ask the model about different properties (e.g., only the geographical
coordinates or also the type of Point of Interest some object may have).

We have already mentioned that a good knowledge representation system should
facilitate both the acquisition of knowledge and its use, including reasoning
based on its representation. In general, a good representation of both
knowledge and information facilitates the subsequent task on which the
representation is operated and increases the efficiency or speed of its
solution, such as being easier to process by machine learning models or making
it easier to answer questions. And it is often in terms of the task that we
choose the suitable representation.

For example, assume that we want to build a machine learning model to
recognize images of animals. In that case, a good data representation might be
images in the form of raw pixels. The model will be able to learn from this
form of input data and will be able to recognize different animals based on
pixel patterns. If, on the other hand, we want to explore relationships
between known scientists, a good option would be to create a graph in which
the nodes are individuals, and the edges are labelled with the types of
relationships between them (e.g., supervisor, co-author). Representing the
data in this way makes finding connections between scientists and determining
the degree of their proximity more simple. For example, we can easily find
people who have published scientific articles together.

Other important aspects are the interpretability and reusability of a given
knowledge model, including ease of modification and addition of new
information. An example of a good knowledge representation in the medical
domain could be a knowledge graph containing information on various diseases,
symptoms and treatments. For example, a knowledge graph might contain
information about various diseases, such as diabetes or heart disease, the
typical symptoms of these diseases and what treatments are available. In this
application, the knowledge graph makes it easy to find and interpret
information about specific diseases and treatments and easily add new
information.

An appropriate knowledge representation should facilitate reasoning. For
example, in a health and nutrition ontology, one can define concepts such as:
disease, diet, nutrient, and drug, as well as relationships between them, such
as: diet supporting the treatment of the disease, drug for the disease or
effect of the drug on the absorption of the nutrient, and constraints, such as
the state of hyperglycemia, concerning blood sugar levels, is disjoint with
the state of hypoglycemia. This representation of knowledge in an information
system, where individual concepts, relationships, and constraints (axioms) are
explicitly represented, should facilitate reasoning about recommended diets
for people struggling with a particular disease. A diet recommendation system,
for example, could include as a component an ontology about diabetes and use
it to infer that diabetes is a disease that requires a special diet and that
certain nutrients are particularly important to be included in the diet for
people with diabetes and certain others should be restricted. As a result, the
system can generate consistent and reasonable dietary recommendations for such
people. Many knowledge representation systems are based on logic to facilitate
inference and ensure that the generated conclusions or recommendations are
consistent and verifiable.

##  2 Logical foundations

_Logics_ are formal languages used to represent information so that
conclusions can be drawn. _Syntax_ defines the forms of statements (sentences)
that can be formulated in a given language (knowledge representation
structures). _Semantics_ defines the _meaning_ of statements, their
_interpretation_ , i.e., it determines the _truth_ of a statements in the
world. Statements in logical form represent certain aspects of the world. On
the other hand, the world is the interpretation that gives meaning (semantics)
to statements in logical form. Meaning in the logical sense is the
relationship between statements in logical form and interpretations, i.e.
possible worlds, including imagined ones.

Logicians typically think in terms of _model_ theories [38]. Models are
formally structured worlds against which truthfulness can be evaluated. We say
that $m$ is a model of the statement $\alpha$ if $\alpha$ is true in $m$. By
$M(\alpha)$ let us denote the set of all models of $\alpha$. The _entailment
(logical consequence)_ means that one thing follows (logically) from another:

$KB\models\alpha$ (1)

The statement $\alpha$ is a logical consequence of the knowledge base $KB$ if
and only if it is true in all worlds where $KB$ is true. $KB\models\alpha$ if
and only if $M(KB)\subseteq M(\alpha)$. A sentence is _valid_ if true in every
model.

The definition of logical consequence can be applied to derive inferences,
i.e., performing _logical inference_. To understand the connection between the
concept of logical consequence and logical inference, we can think of
sentences that are logical consequences of the $KB$ knowledge base, of which
there may be many. Inference algorithms find a subset of such statements as
inferences (conclusions). We say that an inference algorithm $i$ can _derive_
a statement $\alpha$ from the $KB$ knowledge base. An inference algorithm is
_sound_ if only valid sentences are provable using it. An inference algorithm
is _complete_ if every valid sentence is provable using it.

As described above, the semantics of first-order logic is typically defined
using model theory. Statements can be assigned a logical value by defining the
interpretation of the symbols of a given language belonging to the family of
first-order logic. Interpretation
$\mathcal{I}$=($\Delta^{\mathcal{I}},\cdotp^{\mathcal{I}}$) consists of a non-
empty set $\Delta^{\mathcal{I}}$ (domain of interpretation) and interpretation
function $\cdotp^{\mathcal{I}}$. The interpretation function
$\cdotp^{\mathcal{I}}$ assigns elements from the set of the symbols to
$\Delta^{\mathcal{I}}$.

##  3 Semantic networks

_Semantic networks_ are a graphical notation for representing knowledge
represented as a set of nodes (concepts) connected by labelled arcs that
represent relationships between nodes. Figure 1 shows an example of a semantic
network.

Figure 1: An example of a semantic network.

.

Semantic networks became part of artificial intelligence research in the
1960s, however, they had already been used in philosophy, psychology and
linguistics.

The modern manifestation of semantic networks is  _Semantic Web_ [7]. The
technologies of the Semantic Web, including the Resource Description Framework
(RDF), RDF Schema (RDFS) and the Web Ontology Language (OWL), described in the
following sections of this primer, are used to create and disseminate semantic
networks and ontologies in a standardized form to allow global knowledge
exchange on the World Wide Web. The father of the idea of the Semantic Web is
Sir Tim Berners-Lee, who has also invented the World Wide Web.

_Resource Description Framework, RDF_ (https://www.w3.org/TR/REC-rdf-syntax/)
combines the concept of semantic networks with web technologies. The resources
we want to describe can be, for example, specific people, locations, or
abstract concepts.

Data in the RDF model is represented using the so-called ”triple model”, where
sentences are represented as triples consisting of a subject $s$, a predicate
$p$ and an object $o$, for example:

Warsaw is_part_of Poland

where Warsaw is the subject of the triple, is_part_of is the predicate, and
Poland is the object. Such a triple can be visualized as a graph (Figure
2).222The graphical notation is inspired by the one used in a free, open-
source ontology editor and framework Protégé (https://protege.stanford.edu)

Figure 2: An RDF triple represented as a graph.

Generally, there may be several localities with the same name, so the need
arises to mark what resource we are referring to in a unique way. Web
technologies come to the rescue, in particular _global identifiers (Uniform
Resource Identifier, URI)_. Using URIs, we can easily create globally unique
names in a decentralized manner – each domain name owner can create new URI
references. URIs can also serve as a means of accessing information describing
a given resource, much like, known from web technologies, an URL (each URL is
also a special case of a URI). A URI may contain a part, called a fragment
identifier, separated from the base part of the URI by the # symbol. For
example, the role of the fragment identifier in the URI
http://example.edu#Warsaw plays the string Warsaw. Since URI identifiers are
usually long character strings, a simplified, abbreviated version called
qnames was introduced. An URI expressed as a qname consists of two parts: the
namespace and the identifier, separated by a colon. For instance, in edu:
Warsaw, a qname identifier, which refers to the namespace, is edu, while
Warsaw refers to the fragment identifier.

The basic elements of RDF are:

  * •

resources, which are identified by URIs and correspond to nodes in the graph,
e.g. http://example.edu,

  * •

blank nodes, i.e. graph elements that are not given a label or URI identifier,
and are often used to describe objects that do not have their own URI
identifier or to build complex expressions that consist of multiple elements,
when at the same time one does not want to create separate resources for each
element. The strings representing blank nodes start with the characters _:,
and software frameworks create them automatically,

  * •

properties, identified by URIs, corresponding to arcs in the graph, and
representing the binary relationships, e.g. http://example.edu#is_part_of,

  * •

literals that represent specific data values e.g. Warsaw, 2022-05-26.

Now let us formalize our knowledge of RDF graphs. Let us consider the pairwise
disjoint sets $\mathbf{U}$, $\mathbf{B}$ and $\mathbf{L}$. They denote
resources (URI references), blank nodes, and literals. _RDF triple_ is a tuple
$t=(s,p,o)\in(\mathbf{U}\cup\mathbf{B})\times\mathbf{U}\times(\mathbf{U}\cup\mathbf{B}\cup\mathbf{L})$,
where $s$ is the subject, $p$ is the predicate, and $o$ is the object of the
triple. _RDF graph_ (or RDF dataset) $\mathcal{G}$ is a set of RDF triples.

Since we only deal with, at most, binary relations in an RDF graph, how can we
represent relations that are inherently $n$-ary in such a graph? We can use
the _reification_ design pattern, illustrated in the following example.

Example 1 (Reification). Now, let us examine the task of transforming a given
table from a relational database into an RDF graph that reflects the meaning
and relationships of the data in the table. For the purposes of our task, we
will use Table 2, which contains shopping data.

Table 2: Data on purchases. Buyer | Seller | Product | Number of pieces
---|---|---|---
Marcin Kowalski | Shop1 | Natural yoghurt | 5
Aleksandra Nowak | Shop2 | Butter | 2

In the case under consideration, the ’purchase’ relationship has more than one
participant, being in this relationship. In addition, none of the table’s
columns stands out as leading for the relationship (purchase). When we
encounter such a situation, it is worth using the following design pattern,
the so-called _reification_. We create an instance representing a relation
with links to all instances that are in this relation. We will represent the
$n$-ary relation in the RDF model by creating just such a new instance
representing the relation between $n$ specific instances.

Figure 3: RDF graph depicting $n$-ary purchase relationship.

This requires creating a total of $n$+1 triples: one to create the main
instance of the relationship and one for each object that is in that
relationship. Following the given pattern, and assuming that our namespace
will be http://example.edu, the first row of the table can be visualized as an
RDF graph as in the Figure 3. The set of triples corresponding to this graph
is as follows:

    edu:purchase1 rdf:type edu:Purchase
    edu:purchase1 edu:product edu:NaturalYoghurt
    edu:purchase1 edu:number_of_pieces "5"
    edu:purchase1 edu:buyer edu:MarcinKowalski
    edu:purchase1 edu:seller edu:Shop1

$\blacksquare$

##  4 Frames

_Frame_ is a complex data structure used in artificial intelligence to
represent stereotypical situations or events. Frames, as a form of knowledge
representation, are derived from semantic networks and are a specific version
of them. A frame is a representation of an object or category and allows one
to collect information about them. It has attributes and is in relationships
with other objects or categories. This way of representing and organizing
knowledge reflects the structure of the real world. Two types of frames can be
distinguished:

  * •

individual (represent a single object, such as a specific city),

  * •

general (represent a category of objects, e.g., cities).

A single frame is a named list of _slots_ that are filled with _facets_. Slots
are individual pieces of information that make up a given frame, such as:

       (frame-name
           <slot-name1 facet1>
           <slot-name2 facet2> ...)

A frame reflects the previously accumulated experience of specific situations
through defined and default values. General frames have a slot IS-A, which is
filled in with the name of another general frame, such as:

    (Carrots
      <:IS-A Vegetables>
      <:colour orange>  ...)

More specific frames inherit facets from more general frames. Individual
frames have a slot INSTANCE-OF, which is filled with the name of the general
frame, e.g.:

    (warsaw
      <:INSTANCE-OF City>
      <:voivodeship mazowieckie>
      <:population 1 860 281>  ...)

Inference using a frame is done by:

  * •

consistency checking when filling a slot with a value,

  * •

inheritance of defined and default values (according to IS-A, INSTANCE-OF).

One way frame-based knowledge representation manifests itself in modern
systems is through the use of frame semantics. Frame semantics is an approach
to natural language processing that uses frame-based representations to
understand or generate natural language. It can be used in applications such
as information extraction, machine translation, and dialogue systems. An
example of the practical use of this idea is FrameNet [5], a lexical database
of English containing syntactically and semantically labelled examples of
sentences from a corpus of texts. FrameNet consists of so-called semantic
frames. A semantic frame is a description of the type of event, relation or
entity and the units that constitute it. It consists of frame elements (frame
roles) and lexical units, i.e., words that are found in the text invoke the
frame. In addition, sentences from the corpus annotated with frame elements
are attached to the frame.

Example 2. Consider an example of a frame called Cooking, which represents the
general concept of cooking and contains a number of slots that represent
different aspects of cooking, such as a cook, ingredients, cooking method and
cooking equipment. Some examples of lexical units (words or phrases that can
invoke the frame) include cooking, baking, grilling, etc. Some examples of
frame elements, specific slots in the frame that represent different aspects
of a concept, are Cook, Produced_food, Ingredients, Container.

A sample sentence that fits into this example, where we can find the lexical
unit associated with the frame Cooking might look like this:
Today Maria is going to (bake) [the lexical unit that invokes the frame] a
raspberry cake.
In this sentence, we have an example of a lexical unit bake that triggers the
frame Cooking as well as frame elements such as Produced_food (raspberry cake)
and Cook (Maria). Some frame elements (e.g., Container) are not specified.
$\blacksquare$

In a dialogue system, frame semantics can be used to help the system
understand the user’s intent. For example, if a user asks a question about the
weather, the system can use frame semantics to identify the appropriate frame
associated with the intent (e.g., weather_forecast) and fill in the
appropriate fields associated with that intent (e.g., location, date) to
generate a response.

Frame semantics is also used in Wikipedia, where it represents relationships
between different concepts and provides context for articles. For example, a
Wikipedia article about a particular city might include a frame (called an
Infobox) that contains information about the city’s location, population, and
other typical data. This allows readers to more easily access additional
related information.

Knowledge representation in the form of frames and frame semantics is also
used in robotics to help robots understand their environment and interact with
it. In this context, frames represent various concepts and objects a robot may
encounter, such as furniture or tools. In addition, the slots in each frame
can contain information about the object’s physical characteristics, such as
size, shape and colour, as well as its function and use. Frame-based inference
systems may allow robots to use knowledge about the environment to make
decisions and take actions. For example, a robot can use its knowledge of
objects in a room to navigate through it or to recognize and identify specific
objects. Frame semantics can also be used in natural language processing,
allowing robots to understand and respond to human commands and questions. For
example, a robot can use frame semantics to understand the intent behind the
command “pick up the red cup” by identifying the appropriate frame (e.g.,
object_manipulation) and filling in the appropriate fields (e.g., object to be
manipulated, object’s features).

Knowledge representation using frames played a significant role in developing
early ontologies and tools for knowledge representation and manipulation. One
example is the Protégé system, a popular software platform for building,
editing and manipulating ontologies. In Protégé, a knowledge representation
framework is used to represent concepts and their relationships in the form of
frames, which consist of a collection of slots and fillers. Each frame
represents a specific concept, and the slots represent properties or
characteristics of that concept. Fillers are specific values that are assigned
to each slot.

Using frame knowledge representation and frame semantics in ontologies and
tools such as Protégé helped provide a structured and organized way to
represent and manipulate knowledge, enabling users to manage and use large
amounts of information more effectively.

##  5 Ontologies

The word _ontology_ originated in philosophy. Ontology, as a philosophical
discipline, was first studied by Aristotle. In his important philosophical
work “Metaphysics” Aristotle defined what later became known as ontology, or
the science of “being as being”, which studies the nature of entities and
their attributes. Ontology deals with describing and categorizing entities
based on their structure and properties.

In computer science, ontologies are formal representations of concepts,
relationships, and constraints within a domain that facilitate communication
and understanding between multiple parties. In computer science, ontology is
an engineering artefact, i.e., not the study of entities and their
categorization but the concrete result of such categorization. Therefore,
although from a philosophical perspective, ontology can be seen as a
particular system of categories responsible for a certain vision of the world,
independent of its representation, in computer science, an ontology is
dependent on the languages used to represent it. Several definitions of
ontology have been proposed in this context. Ontology is defined by Gruber as
a “formal, explicit specification of a shared conceptualization of a domain of
interest” [17]. Formality is about making the ontology explicit for
interpretation by machines. Clarity refers to making sure that all concepts
and their interrelationships are clearly defined. Sharing refers to the
ontology’s capture of some consensus in modelling concepts, accepted by a
community or several stakeholders, rather than an individual view. The domain
of interest is established between the requirements of a specific application
and the “unique truth”. Another definition of ontology in computer science by
Uschold states that it is “the representation, formalization and specification
of important concepts and relationships within a given domain” [40]. This
definition emphasizes the role of ontology in representing and specifying key
concepts and relationships within a given domain, as well as formalizing these
concepts and relationships.

Among the available ontologies, we can distinguish between foundational
ontologies, i.e. ontologies that define the basic concepts and distinctions,
the types of entities existing in the world and the relationships between
them, such as objects fixed in time versus events or real or abstract objects.
For example, the DOLCE [16] or BFO [2] ontology fall into this category.

On the other hand, domain-specific ontologies are designed to represent
domain-specific concepts and relationships. Examples of such ontologies
include biomedical ontologies, such as the SNOMED ontology, which is used to
represent medical concepts and their relationships, the GO ontology, which is
used to represent gene functions, or CHEBI, an ontology of biologically
relevant chemical compounds.

To model ontologies, a number of representation languages have been proposed
that provide various kinds of features. The most widespread have been
languages based on the first-order logic since it is equipped with formal
semantics and thus facilitates machines’ interpretability of encoded
knowledge.

###  5.1 RDFS language

Simple ontologies can be represented using _RDFS language (RDF Schema)_
(https://www.w3.org/TR/rdf-schema/). RDFS belongs to the Semantic Web
technology stack. It integrates with RDF by enriching data with its semantics
formulated in the form of a data schema. Figure 4 illustrates an example of
the semantic network, where RDF is the data layer and RDFS is the data schema
layer.

Figure 4: RDFS-represented data schema layer embedded on RDF-represented data
layer, together forming a single semantic network.

.

RDFS introduces a distinctive vocabulary to indicate to inference (reasoning)
engines what conclusions they should derive from the facts being modelled. To
model class hierarchies, RDFS includes the keyword rdfs:subClassOf, with which
we can model that class $C_{1}$ is a subclass of class $C_{2}$. So, for
example, we can model that class City is a subclass of class Locality.
Continuing with the example, if then the knowledge base contains the following
triple:

Warsaw rdf:type City

then we can infer (deduce) that

Warsaw rdf:type Locality

which allows us to model and infer the class hierarchy.

Similarly, we can use the property rdfs:subPropertyOf to model the fact that
property $P_{1}$ is a subproperty of property $P_{2}$. For example, we can
model that is_district_of is a subproperty of is_part_of and then given facts:

Ursynów is_district_of Warsaw

then we can infer that

Ursynów is_part_of Warsaw.

In addition, RDFS introduces a vocabulary for defining domain constraints
(rdfs:domain) and range constraints (rdfs:range). When we denote the domain of
property $P_{1}$ as class $C_{1}$ and there is a fact entity1 $P_{1}$ entity2
in the knowledge base, the inference will be that the instance entity1 belongs
to class $C_{1}$. Similarly, we can introduce a range constraint (rdfs:range)
to limit the membership of a given class of objects (the third element) of the
triple. For example, if there are the following facts in the knowledge base:

is_district_of rdfs:range City
Ursynów is_district_of Warsaw

then we can infer that

Warsaw rdf:type City

###  5.2 OWL ontology modeling language

The most popular, standard ontology modeling language is the _OWL (Web
Ontology Language)_ (https://www.w3.org/TR/owl-features/). Standardizing the
knowledge representation language helps in creating tools for editing
knowledge represented in the language and also in developing reasoning
engines. OWL allows describing concepts (classes) in a formal, unambiguous
way, based on set theory and logic. OWL ontologies are implementations of
_description logic_ [4], which is a subset of the first-order logic.

Knowledge bases represented using description logic typically consist of a
terminological part, i.e. the schema of the knowledge base, and an assertional
part, i.e. the data in the knowledge base._The terminological part
(terminological box, TBox)_ contains the vocabulary used to describe the
hierarchy of classes and relationships in the knowledge base. _The assertional
part (assertional box, ABox)_ contains statements about properties of
instances.

OWL extends RDF and RDFS by providing additional vocabulary. OWL can be
written using RDF syntax, where expressions containing OWL vocabulary are
embedded in RDF documents and interpreted according to OWL semantics. Other
common ways of writing OWL are turtle and the Manchester syntax. References to
syntax formalized with description logic can also often be encountered.

The main elements that make up an ontology represented in OWL are:

  * •

_entities_ – classes, properties, individuals (instances) and any other
elements of the modelled domain. A class is interpreted as a set, a property
as a binary relation, and an individual as an element of a set;

  * •

_expressions_ – complex classes occurring in the modelled domain;

  * •

_axioms_ – assertions that are true in the modelled domain.

The ontology represented in OWL is a set of axioms.

Classes represent collections of individuals (instances). For example, by
writing City rdf:type owl:Class, we can express that City is the class of
cities, which includes instances such as Warsaw, Poznan, etc. The two special
classes are: the universal class owl:Thing, which represents the set of all
instances, is a superclass of all classes, and its interpretation is the
entire domain under consideration, and the bottom class owl:Nothing, which
represents the empty set of instances, i.e. constraints that are impossible to
satisfy all together (its interpretation is the empty set).

Complex classes can be built from simpler classes using logical operators.
This gives us a “conceptual Lego”, where we construct complex classes from
other (potentially complex) classes.

Let us denote (complex) classes by $C,D$, properties by $R,S$, and individuals
(instances) by $a,b$. Examples of operators and their representation in
description logic and turtle notations are shown in Table 3.

Table 3: Examples of logical operators that can be used in OWL to construct complex classes shown using description logic and turtle syntaxes. Operator | Syntax |  Example |  Example
---|---|---|---
| (description logic) |  (description logic) |  (turtle)
universal class | $\top$ |  $\top$ |  owl:Thing
bottom class | $\bot$ |  $\bot$ |  owl:Nothing
negation | $(\neg C)$ |  ( $\neg$ Meat ) |  owl:complementOf Meat
intersection | $(C\sqcap D)$ |  ( Child $\sqcap$ Man) |  owl:intersectionOf (Child Man)
union | $(C\sqcup D)$ |  ( Herbivore $\sqcup$ Carnivore $\sqcup$ Omnivore ) |  owl:unionOf (Herbivore Carnivore Omnivore)
existential | $(\exists R.C)$ |  ( $\exists$eats.Meat ) |  owl:onProperty :eats ;
quantification |  |  |  owl:someValuesFrom :Meat
value | $(\forall R.C)$ |  $(\forall$eats.VegetarianProduct ) |  owl:onProperty :eats ;
restriction |  |  |  owl:allValuesFrom :VegetarianProduct

Because of the _Open World Assumption, OWA_ , discussed later in this primer,
it is worth noting the interpretation of some operators, particularly
negation. Negation is interpreted in OWL as a complement, as illustrated in
the Figure 5 on the left, referring to the expression owl:complementOf Meat.

Figure 5: Interpretation of negation as complement (left) and complement in
the context of superclass (right).

In practice, inferring all imaginable non-meat objects, including those
unknown and not described in the knowledge base is challenging. Therefore, to
infer negation, it is often captured in the context of a superclass (e.g.,
FoodProduct), which describes a set of instances, some of which are, for
example, meat and the rest are other instances belonging to the class
FoodProduct as illustrated in the Figure 5 (right), where the area marked in
light gray is the complement of a white and dark gray circle relative to the
rectangle surrounding the whole. The class of things that vegetarians eat is
in the area marked in dark gray.

Properties exist independently of classes. Properties in OWL are divided into:

  * •

object properties that link a resource to another resource, e.g. the property
is_part_of can link instances Ursynów and Warsaw,

  * •

data properties that connect a resource to a literal, e.g. the weight property
can associate a given product with its weight,

  * •

annotation properties that link the resource to a note about it, e.g.
rdfs:label links the resource to its label.

In addition, properties can have their own characteristics, of which we can
distinguish:

  * •

inverse property, e.g.:

        :is_parent_of rdf:type owl:ObjectProperty ;
                   owl:inverseOf :has_parent .

  * •

functional property, e.g:

        :has_father rdf:type owl:ObjectProperty ,
                     owl:FunctionalProperty .

  * •

transitive property, e.g:

        :is_part_of rdf:type owl:ObjectProperty ,
                          owl:TransitiveProperty ;
                 rdfs:domain :Region ;
                 rdfs:range :Region .

For classes, we can define three main types of axioms that define
relationships between classes (also shown in Table 4):

  * •

_subsumption_ ,

  * •

_equivalence_ ,

  * •

_disjointness_.

Table 4: The main axioms in the OWL language that define the relationships between classes presented by means of two syntaxes: the description logic syntax and the turtle syntax. Axiom |  Syntax |  Example |  Example
---|---|---|---
|  (description |  (description |  (turtle)
|  logic) |  logic) |
subsumption |  $C\sqsubseteq D$ |  Boy $\mathsf{\sqsubseteq}$ Child |  Boy owl:subClassOf Child
equivalence |  $C\equiv D$ |  Country $\mathsf{\equiv}$ State |  Country owl:equivalentClass State
disjointness |  $\mathsf{C}\sqcap\mathsf{D}\sqsubseteq\bot$ |  Herbivore $\sqcap$ Carnivore $\sqsubseteq\bot$ |  Herbivore owl:disjointWith Carnivore

Analogous axioms can be defined for properties, but they are much less
frequently specified due to the _entity-centric_ characteristics of the
ontologies represented in OWL.

We introduce the subsumption relation using the keyword owl:subClassOf. By
modelling the subsumption relation, we introduce the necessary conditions that
instances of a class must satisfy. In this way, we model semantic class
descriptions. One can interpret such a relation as a one-way implication. For
example, we may wish to model that “all carnivores eat meat”:

    :Carnivore rdf:type owl:Class ;
           rdfs:subClassOf [ rdf:type owl:Restriction ;
                            owl:onProperty :eats ;
                            owl:someValuesFrom :Meat
    ΨΨΨ   ] .

The keyword owl:equivalentClass represents an equivalence relation. We model
class definitions in this way. Such a relation can be interpreted as a two-way
implication, which defines the necessary and sufficient conditions to consider
an instance of a class as an instance of another class and vice versa. This
means that equivalent classes share the same set of instances. For example, we
may want to model that “every boy is a child and a man” and at the same time
“everyone who is a child and a man is a boy”:

    :Boy rdf:type owl:Class ;
    Ψ     owl:equivalentClass [ rdf:type owl:Class ;
    ΨΨΨ                   owl:intersectionOf ( :Child  :Man )
    ΨΨΨ ] .

As long as we do not explicitly introduce the _disjointness constraint_ ,
classes can share instances. If we want that a given instance cannot belong to
two given classes at the same time, we can introduce the axiom of class
disjointness using the keyword owl:disjointWith. For example, given the
following statements:

Herbivore owl:disjointWith Carnivore

Pumpkin rdf:type Carnivore

we can infer that Pumpkin is not a herbivore. The introduction of disjointness
constraints into ontologies is very important from the point of view of
checking the consistency of an ontology or knowledge base.

At the level of individuals (i.e. instances of classes), there are two main
types of axioms:

  * •

assertions of individuals to classes, e.g.: Warsaw rdf:type City, and

  * •

assertions of individuals to properties, e.g.: Ursynów is_district_of Warsaw.

The owl:sameAs property has an important role in reconciling entities that
have different identifiers but are semantically equivalent to each other. In
contrast, when wishing to express that given instance identifiers refer to
different objects, we can use the property owl:differentFrom (modelling the
relationship between two instances) or owl:allDifferent (modelling the
relationship between instances from a set as pairwise disjoint).

####  5.2.1 Reasoning

The use of logic to model ontologies allows the use of inference engines. We
can use inference engines, e.g. to check that all statements and definitions
in the ontology are mutually consistent, to check which classes are in a
superclass-subclass relationship (subsumption relationship) with each other
automatically, and others. Inference can thus keep the hierarchy of classes in
the ontology in the right order.

The basic inference tasks in OWL can be divided into schema (,,terminological”
part of the ontology) inference tasks and instance (,,assertional” part of the
ontology) inference tasks.

For the terminology (i.e. TBox) these are:

  * •

checking whether a given (complex) class $C$ is a subclass of another class
$D$ in a logical sense (subsumption test), i.e. whether $C$ owl:SubClassOf $D$
is a logical consequence of $KB$ (the set of instances of class $C$ is a
subset of instances of class $D$ in all $KB$ models),

  * •

checking whether a given (complex) class $C$ is logically equivalent to
another class $D$ i.e. whether $C$ owl:EquivalentClass $D$ is a logical
consequence of $KB$ (the set of instances of class $C$ is equal to the set of
instances of class $D$ in all $KB$ models),

  * •

checking whether a class is _satisfiable_ , whether the set of constraints
describing it is not contradictory, i.e. whether $C$ owl:EquivalentClass
owl:Nothing is not a logical consequence of $KB$ (the set of instances of
class $C$ is not an empty set for some $KB$ model).

The inference tasks typical of the assertional part, ABox, are:

  * •

checking whether the ABox is _consistent_ , i.e. whether it has a model, the
so-called task of _consistency checking_ ,

  * •

checking whether a given individual $a$ is an instance of a given class $C$ in
the logical sense, the so-called task of _instance checking_ ,

  * •

given an ABox and a class $C$, finding all individuals $a$ such that the
assertion $a$ rdf:type of $C$ is a logical consequence of the ABox, so-called
_retrieval problem_ ,

  * •

having an individual $a$ and a set of classes, finding _most specific class_
$C$ from the set such that the assertion $a$ rdf:type $C$ is a logical
consequence of ABox, so called _realization problem_.

Satisfiability and consistency tests can be used to determine the
meaningfulness of the $KB$ knowledge base. Subsumption tests are often used to
automatically construct class hierarchies. Instance tests are queries designed
to return individuals that satisfy the query conditions.

####  5.2.2 “Closed world assumption” versus “open world assumption”

Inference engines in OWL operate on certain assumptions, which sometimes
differ from those made to query relational databases, for example. When
dealing with a standard, centralised database, the so-called “closed-world
assumption” is made, i.e. that we have complete knowledge of the instances and
that missing information is negative information (negation-as-failure).
However, by querying the knowledge base represented in the OWL language, we
assume incomplete knowledge of instances. Any negation of a fact must be
explicitly stated.

Example 3 (Assumption of “open world”). Consider an example illustrating how
making a given assumption about the “closedness” or “openness” of the world
affects inference. The Table 5 represents information from the knowledge base
under development regarding food products and the allergens that may be
present in their composition.

Table 5: Food products and the allergens typically found in them. Product | Allergens
---|---
wheat flour | gluten
dark soy sauce | soya
sausages | soya, gluten
cream | milk
peanuts | nuts

Let us assume that we want to query the knowledge base on gluten-free
products. Assuming a “closed world”, the answers would be: soy sauce, cream
and peanuts. However, in reality, both cream and soy sauce may contain gluten
in their composition, only this information may not have been included in the
knowledge base yet. In order to be sure of the results of inference under the
assumption of an “open world”, it would be necessary to include axioms
explicitly stating that, for example, peanuts do not contain gluten into the
knowledge base. $\blacksquare$

####  5.2.3 Lack of unique names assumption

Unlike most knowledge representation languages, OWL inference does not use the
_Unique Names Assumption, UNA_ , which is the assumption that distinct names
denote distinct objects. In order to model knowledge in decentralised
environments such as the Internet, it has been assumed that anyone can call
anything by any name. Therefore, names cannot be assumed to be unique.
However, different names do not necessarily mean different objects either. For
example, two different names, Madame Curie and Maria Sklodowska-Curie, can
refer to the same person. In addition, a person may be represented in some
knowledge bases by alphanumeric identifiers, e.g. wikidata:Q7186.

Example 4 (Lack of assumption on uniqueness of names). The lack of assumption
about uniqueness of names also affects the results of inference using
functional properties. Suppose we have the following axioms in the knowledge
base:

    Ola has_father Jan
    Ola has_father Marcin
    has_father rdf:type owl:FunctionalProperty .

What conclusions will be derived from such a knowledge base? Will the
inference engine show a contradiction? Well, due to the fact that has_father
is the functional property and the lack of assumption of uniqueness of names,
when the inference engine is run, a fact will be generated regarding the
identity of the instances of Jan and Marcin i.e.: Jan owl:sameAs Marcin.
$\blacksquare$

##  6 Knowledge graphs

A _knowledge graph_ is a large, graphically structured knowledge base that
represents facts in the form of relationships between entities. The basic
building blocks of a knowledge graph are: entities, expressed through nodes in
the graph, their properties (attributes) and the relationships connecting the
nodes, expressed through edges in the graph. Entities may have (semantic)
types, which is represented by the relation is-a between an entity and its
type. It is also possible that some types, properties and relationships stored
in the knowledge graph are structured in an ontology or data schema.

Example 5 (Knowledge graph). Figure 6 shows an example of a knowledge graph.

Figure 6: Example of a knowledge graph that contains classes, instances and
data of a specific type.

.

The graph uses vocabulary from the RDF, RDFS and OWL namespaces, which are
denoted in the figure by the prefixes rdf:, rdfs: and owl: respectively. The
instance Maria_Sklodowska_Curie is linked to its semantically equivalent
instance wikidata:Q7186 (which has an alpha-numeric identifier) in the
Wikidata knowledge base via the property owl:sameAs. The instance
wikidata:Q7186 belongs to the class Person and its type (class) is specified
by using the property rdf:type. The class Scientist is related to the class
Occupation through the property rdfs:subClassOf, meaning that it is a subclass
of it, as well as through the property owl:equivalentClass to the class
wikidata:Q901, meaning that they are semantically equivalent classes. In the
figure we have examples of both object properties and datatype properties. An
example of the first of these is the discipline property, which links two
objects, among others: Maria_Sklodowska_Curie and Chemistry. An example of the
second of these is the birthdate, which associates the Maria_Sklodowska_Curie
object with a 1867-11-07 value that belongs to a specific data type, denoted
via the xsd:date namespace as date. $\blacksquare$

More formal definitions specify a set of entities $\mathcal{E}$, a set of
relations $\mathcal{R}$, and a knowledge graph as a directed multi-relational
graph $\mathcal{G}$, representing facts or assertions as triples $(s,p,o)$,
consisting of a subject $s$, a predicate $p$, and an object $o$, where

$\mathcal{G}\subseteq\mathcal{E}\times\mathcal{R}\times\mathcal{E},$ (2)
$(s,p,o)\subseteq\mathcal{G}$ (3)

We can see a similarity with the already presented examples of semantic
networks, the definition of RDF triples, or ontologies. How, then, does a
knowledge graph differ from a graph composed of RDF triples or from an
ontology? Not every knowledge graph uses RDF vocabulary and Semantic Web
technologies, although many knowledge graphs are represented using these
technologies. In a knowledge graph, an ontology is a kind of data schema that
imposes semantics, meaning on the data, and usually has a shallow level of
axiomatisation or is a small part of the knowledge graph. Knowledge graphs, on
the other hand, are focused on data (instances) and the number of instances in
a typical knowledge graph can be huge. It can be said that a knowledge graph
is a kind of semantic network with added constraints. Due to this much larger
scale, also the methods of knowledge acquisition or inference using the
knowledge graph have to be adapted to this larger scale. One can observe a
shift of attention from manual knowledge engineering methods, focusing on rule
modelling and ontologies, to automatic or semi-automatic methods, often using
data mining or machine learning or _crowdsourcing_ 333Crowdsourcing refers to
the practice of obtaining services or content by soliciting input from a large
group of people, usually via the Internet. Crowdsourcing projects often
involve breaking larger projects into micro-tasks, separate units of work that
can be done independently and quickly, and outsourcing them to a range of
collaborators rather than to a single person or organisation. The term is a
combination of “crowd” and “outsourcing” and was coined in 2006 by Jeff Howe .
Also, knowledge graph inference makes more use of graph data structure and a
triple data model than complex logical inference and logical interpretation of
data in the form of ontology axioms, and is often performed using statistical
or neuro-symbolic methods and learning sub-symbolic representations of
knowledge graphs (knowledge graph embeddings [42]).

Depending on the availability of the knowledge graph, how it is built (within
an organisation or through a community) the result can be an open or corporate
knowledge graph. Open knowledge graphs are publicly available. Well known
examples of such graphs are DBpedia [3], Wikidata [41], YAGO [37]. They cover
many domains and offer multilingual lexicalisation. Open knowledge graphs can
also address specific domains such as media, geography and others.

Corporate knowledge graphs are internal within a particular company and are
aimed at commercial applications. Corporate knowledge graphs are used in
industries such as web search, e-commerce, social networks, pharmaceuticals,
finance and others. Typical applications of knowledge graphs include semantic
search, question answering, intelligent assistants, innovation support in
research and design (such as the design of new drugs).

###  6.1 Knowledge graph construction

The typical knowledge graph construction process starts with the acquisition
of a corpus and ends with a graph ready for application. Typically, this
process can be illustrated by two main phases: _knowledge extraction_ and the
construction of the knowledge graph (including its completion or refinement)
as illustrated in Figure 7.

Figure 7: Knowledge graph construction process.

The first stage involves extracting knowledge from both unstructured (e.g.
text) and structured (e.g. relational databases) and semi-structured sources
or by converting existing data (e.g. csv files). Natural language processing
and information extraction methods can be used for this purpose. The task of
knowledge extraction includes using existing knowledge resources (knowledge
bases, ontologies) or generating a schema from source data.

The specific task we may therefore have to deal with at this stage is _entity
linking_. Entity linking is the process of identifying and tagging mentions of
specific objects in the text and linking them to the corresponding entities
(their identifiers) in external knowledge bases, databases, or ontologies. For
example, in the text Jan Kowalski has seen Chicago, an entity linking system
could tag the entities Jan Kowalski and Chicago and link them to the
corresponding pages in Wikipedia or identifiers in Wikidata. Sometimes there
can be ambiguity as to which specific entity a mention should be linked to.
The entity linking system has to deal with the problem of determining whether
the text Chicago refers to a city, a musical or a movie. Similarly, it may not
be certain whether the mention of “Jan Kowalski” refers to an athlete, a
writer, etc. In such situations, the system must take this ambiguity into
account and help select the appropriate entity to link to the mention in the
text.

Once created using knowledge extraction methods, the knowledge graph may
contain a lot of noisy and incomplete data. The purpose of the _knowledge
graph completion_ task is precisely to fill in missing information and
intelligently clean the data in the knowledge graph. This is usually solved by
completing missing edges through link prediction, entity deduplication
(eliminating repeated entities) and dealing with missing values.

_Link prediction_ in knowledge graphs is the problem of predicting missing
relationships between entities in a knowledge graph. Missing relationships can
be useful to complete the linking of missing information in a knowledge graph
or to improve the accuracy of various applications, such as recommender
systems or question answering.

There are many different approaches to solving the problem of predicting
relationships in knowledge graphs, including regression-based, classification-
based and ranking-based approaches. All of these approaches require learning a
model on a large dataset containing existing relationships in the knowledge
graph, and then using this model to predict missing relationships.

One of the most commonly used approaches is learning knowledge graph
embeddings. In this approach, entities and relationships in a knowledge graph
are represented as vectors in a low-dimensional vector space, and the model
learns these vectors from a large dataset containing existing relationships in
the knowledge graph. Then, to predict a missing relationship between two
entities, the model compares the vectors of these entities and predicts how
probable is that they are connected by a given relationship.

###  6.2 Knowledge graph representation learning

Representation learning involves embedding a data element, which can be, for
example, a piece of text, an entity, a relation in a vector space. _Knowledge
graph embedding_ is performed using supervised machine learning on a large
dataset of triples to project knowledge graph components onto a continuous and
low-dimensional vector space. The aim of knowledge graph embedding is to
capture the semantics of entities and relationships in the knowledge graph in
a way that will facilitate use in a variety of tasks, be it tasks related to
construction of the knowledge graph (such as its completion) or downstream
tasks such as its use in recommender systems.

In particular, for any pair ${s,o}\subseteq\mathcal{E}$ and relation
$p\in\mathcal{R}$, it can be determined whether the sentence $(s,p,o)$ is true
according to the data embeddings of the knowledge graph.

The knowledge graph embedding model consists of:

  * •

a knowledge graph $\mathcal{G}$,

  * •

a strategy for generating negative examples,

  * •

an evaluation function of the triple $f(t)$,

  * •

a loss function $\mathcal{L}$,

  * •

a lookup layer,

  * •

an optimization algorithm.

The architecture of such a solution, depicted by the authors of one of the
popular libraries for learning knowledge graph representations [13], is shown
in Figure 8.

Figure 8: Architecture of a system for creating knowledge graph embeddings.

A number of different approaches to training knowledge graph embeddings have
been proposed, including translation-based approaches, tensor-based approaches
and graph-based approaches. For example, the TransE model, one of the first
translation-based embedding methods to have been proposed, works on the simple
principle that the combination of subject and relation vectors should ideally
be equal to the object vector. TransE is able to learn composition, inverse
and antisymmetry.

##  7 Large language models as knowledge bases

As we described in Section 6.1, creating and populating knowledge bases
requires knowledge extraction from different data formats. Traditionally, this
requires a fixed data schema and the application of NLP methods in several
steps, where each step can propagate errors to the next step. Petroni et al.
[33] have shown that instead of the classical approach, _large language models
(LLMs)_ can be used as a source of knowledge. Such models, sometimes called
_Foundation Models_ , are deep neural networks scaled to billions of
parameters on the task of predicting the next word on a large corpus and
storing the knowledge that was contained in the training data implicitly. They
can generalise to new tasks without fine-tuning to answer questions structured
as “fill-in-the-blank” cloze statements, such as: “The colour of a carrot is
[MASK]”.

This approach does not require manual engineering of the knowledge schema or
human annotation of the data to extract relatively good-quality knowledge.
Narayan et al. [30] have shown how knowledge cleaning and integration tasks,
including entity matching, can be performed by reformulating them as prompting
tasks. For example, they examined the answer to the question “Are products A
and B the same?” and the language model generated a string “Yes” or “No” as
the answer.

###  7.1 Prompt engineering

_Prompt engineering_ (_in-context prompting_) [6] concerns methods of
communicating with LLMs to get desired answers. The weights of the model stay
unchanged. The models can be trained to learn a task in a few-shot manner
(with minimal task description) or even in a zero-shot learning setting [12].
Prompt engineering is mostly an experimental field of study. The terminology
is relatively simple and is introduced next. _Prompt_ is a conditioning text
before the test input. Zero-shot learning consists of simply providing a text
to get the answer. _Demonstrations_ is an instance of the prompt, which is a
concatenation of the $k$-shot training data. Few-shot learning consists of
presenting a set of demonstrations composed of input and envisaged output, for
instance:

    Lemon: yellow
    Carrot: orange
    Raspberry: raspberry red
    Pear:

_Pattern_ is a function mapping an input to the text. _Verbalizer_ is a
function mapping a label to the text.

###  7.2 Commonsense knowledge

Some datasets and knowledge graphs are designed to capture commonsense
knowledge, such as the knowledge of physical phenomena that humans acquire
during their lives as part of their interaction with the environment or
knowledge required in scientific computing. For example, ConceptNet [35] is a
knowledge graph that connects structured knowledge to natural language,
bridging the gap between formal knowledge representation and natural language.
It connects words and phrases with labelled edges. It gathers knowledge from
the resources developed by experts, crowd-sourcing, and games with a purpose.
Further linking this graph with text embeddings helps to solve tasks such as
SAT-style analogies more efficiently than with resources based primarily on
formalised knowledge structure.

Benchmarks designed to evaluate commonsense reasoning often come with the task
of question answering. For instance, PIQA (“Physical Interaction – Question
Answering”) [9] is a dataset related to best achieving a goal in everyday
tasks such as crafting, baking, or manipulating objects using everyday
materials. The user has to choose one of the two answers concerning how to
achieve the goal best. One of the answers is the right one. For instance, if
one asks how to eat soup, the correct answer is to use a spoon rather than a
fork. Answering such questions requires knowledge that may not be represented
explicitly as, e.g., attributes of some object (as factual knowledge) and also
might depend on context. Consider, for instance, querying an LLM on the
functions (roles) of some ingredients in a dish (implicit and contextual
knowledge):

       sugar [DISH] cake [FUNCTION] sweetener
       baking powder [DISH] cake [FUNCTION] leavening agent
       egg yolk [DISH] Hollandaise sauce [FUNCTION] emulsifier
       yeast [DISH] bread [FUNCTION]

Answering such queries may require the model to understand food technological
processes.

##  8 Knowledge engineering methodology

There are a number of methodological issues and best practices associated with
knowledge engineering. Several of these are discussed below.

###  8.1 URIs and multilinguality

We can adopt one of two main naming conventions when specifying a URI for a
resource.

One is to name the resource directly in its URI, i.e., insert the resource
name in the URI string, such as geo:Warsaw. The advantages of such a solution
are simplicity, ease of interpretation and greater availability of tools that
support such a format without problems.

The second convention is to create an alphanumeric resource identifier and put
the name in the label using predefined annotation properties like rdfs:label,
for example: geo:locality1 rdfs:label "Warsaw". The advantages of such a
solution are: facilitating multilingualism, and avoiding the problems of
formulating long names, which can be, for example, a concatenation of many
words due to the addition of more and more detailed classes in their hierarchy
(we can put any phrase in the label), ease and flexibility of changes, and
preserving the stability of URI-based application builds in case the semantic
meaning of a resource changes or drifts (it is then enough to change the label
itself and not the identifier).

###  8.2 Ontology engineering methodologies

Knowledge engineering refers to the process of developing knowledge bases,
ontologies and knowledge graphs. In particular, ontology engineering
methodologies have been developed. Early methodologies followed the cascade
model of ontology development, in which requirements and general
conceptualization were established before ontology definition began. However,
nowadays we often deal with large or constantly evolving ontologies, hence the
subsequent methodologies that have been proposed promote more iterative and
agile ways of building and maintaining ontologies [24].

Modern methodologies propose various best practices like reusing already
existing resources to create a network of ontologies that import selected
classes, properties or entire modules among themselves [36]. They often
contain two common elements: ontology requirements and ontology design
patterns [15].

A common way of expressing the requirements that an ontology must meet
includes _competency questions_ , which are natural language questions that an
ontology or knowledge graph should be prepared to answer, i.e., at least
contain the appropriate vocabulary.

_Ontology Design Patterns_ define general ontology modelling patterns
(modelling templates) that can be used as inspiration for modelling more
specific phenomena. An example would be a pattern defining arbitrary events,
which models, among other things, the spatial and temporal scope and the
participants of the event and is supplemented with competency questions and
other documentation elements.

###  8.3 FAIR principles

_FAIR Principles_ were originally proposed in the context of publishing
scientific data [43], but are generally applicable to any situation where data
is to be open, accessible, and published in a way that facilitates its reuse
by external parties, with a particular emphasis on facilitating its processing
in information systems. The FAIR acronym refers to four fundamental principles
for data, metadata or both, each with specific purposes. Below is a brief
discussion of each of the FAIR principles:

  * •

_findable_ : research results should be discoverable and easy to locate, using
persistent identifiers (e.g., DOIs) and metadata that accurately and
comprehensively describe the content.

  * •

_accessible_ : research results should be available to anyone who wants to
access them, regardless of location or ability to pay. This can be achieved
through open-access publishing or other mechanisms that provide free and
unrestricted access.

  * •

_interoperable_ : research results should be structured and formatted in a way
that allows them to be easily integrated and linked with other data and
research results. This requires the use of common standards and protocols.

  * •

_reusable_ : research results should be licensed in a way that allows them to
be reused and built upon by others, subject to proper attribution and
citation.

Adhering to FAIR can help make scientific research more transparent,
reproducible, and influential, advancing science and benefiting society.

##  9 Further reading

A more detailed description of the RDF model can be found in Heath and Bizer’s
book “Linked Data: Evolving the Web into a Global Data Space” [19].

An introduction to description logic can be found in the article by Krotzsch
et al. [28]. A comprehensive textbook on description logic is by Baader et al.
[4]. Description logics are also discussed in a book by Hitzler et al.
“Foundations of Semantic Web Technologies” [20], on the theoretical
foundations of the technologies.

Ontology modelling including topics of engineering, good practices, and design
patterns is presented in the books: “Semantic Web for the Working Ontologist:
Effective Modeling for Linked Data, RDFS, and OWL” by Allemang, Hendler and
Gandon [1] and “Demystifying OWL for the Enterprise” by Uschold [39].
Knowledge engineering (theoretical foundations of ontology representation
languages and good modelling practices) is covered in the publicly available
textbook “An Introduction to Ontology Engineering” by Keet [23].

Knowledge graphs constitute a relatively new, active, and interdisciplinary
area of artificial intelligence that emerged around 2012. They draw from areas
such as natural language processing, data mining, and the Semantic Web. There
are relatively recent textbooks, including “Knowledge Graphs: Fundamentals,
Techniques, and Applications” by Kejriwal, Knoblock and Szekely [25] and
“Knowledge Graphs” by Hogan et al. [22].

Acknowledgments. I thank Robert Nowak, Mieczysław Muraszkiewicz and Students
for helpful remarks on previous versions of this text.

## References

  * [1] Dean Allemang, James Hendler, and Fabien Gandon.  Semantic Web for the Working Ontologist: Effective Modeling for Linked Data, RDFS, and OWL.  Association for Computing Machinery, 2020.
  * [2] Robert Arp, Barry Smith, and Andrew D. Spear.  Building Ontologies with Basic Formal Ontology.  The MIT Press, 2015.
  * [3] Sören Auer, Christian Bizer, Georgi Kobilarov, Jens Lehmann, Richard Cyganiak, and Zachary G. Ives.  DBpedia: A nucleus for a web of open data.  In Karl Aberer, Key-Sun Choi, Natasha Fridman Noy, Dean Allemang, Kyung-Il Lee, Lyndon J. B. Nixon, Jennifer Golbeck, Peter Mika, Diana Maynard, Riichiro Mizoguchi, Guus Schreiber, and Philippe Cudré-Mauroux, editors, The Semantic Web, 6th International Semantic Web Conference, 2nd Asian Semantic Web Conference, ISWC 2007 + ASWC 2007, Busan, Korea, November 11-15, 2007, volume 4825 of Lecture Notes in Computer Science, pages 722–735. Springer, 2007.
  * [4] Franz Baader, Diego Calvanese, Deborah L. McGuinness, Daniele Nardi, and Peter F. Patel-Schneider, editors.  The Description Logic Handbook: Theory, Implementation, and Applications.  Cambridge University Press, 2003.
  * [5] Collin F. Baker, Charles J. Fillmore, and John B. Lowe.  The Berkeley FrameNet project.  In Proceedings of the 36th Annual Meeting of the Association for Computational Linguistics and 17th International Conference on Computational Linguistics - Volume 1, ACL ’98/COLING ’98, page 86–90, USA, 1998. Association for Computational Linguistics.
  * [6] Iz Beltagy, Arman Cohan, Robert L. Logan IV, Sewon Min, and Sameer Singh.  Zero- and few-shot NLP with pretrained language models.  In Luciana Benotti, Naoaki Okazaki, Yves Scherrer, and Marcos Zampieri, editors, Proceedings of the 60th Annual Meeting of the Association for Computational Linguistics, ACL 2022 - Tutorial Abstracts, Dublin, Ireland, May 22-27, 2022, pages 32–37. Association for Computational Linguistics, 2022.
  * [7] Tim Berners-Lee, James Hendler, and Ora Lassila.  The Semantic Web.  Scientific American, 284(5):34–43, 2001.
  * [8] Tarek R. Besold, Artur S. d’Avila Garcez, Sebastian Bader, Howard Bowman, Pedro M. Domingos, Pascal Hitzler, Kai-Uwe Kühnberger, Luís C. Lamb, Priscila Machado Vieira Lima, Leo de Penning, Gadi Pinkas, Hoifung Poon, and Gerson Zaverucha.  Neural-symbolic learning and reasoning: A survey and interpretation.  In Pascal Hitzler and Md. Kamruzzaman Sarker, editors, Neuro-Symbolic Artificial Intelligence: The State of the Art, volume 342 of Frontiers in Artificial Intelligence and Applications, pages 1–51. IOS Press, 2021.
  * [9] Yonatan Bisk, Rowan Zellers, Jianfeng Gao, Yejin Choi, et al.  PIQA: Reasoning about physical commonsense in natural language.  In Proceedings of the AAAI conference on artificial intelligence, volume 34, pages 7432–7439, 2020.
  * [10] Andreas Blumauer and Helmut Nagy.  The Knowledge Graph Cookbook.  edition mono/monochrom, 2020.
  * [11] Ronald Brachman and Hector Levesque.  Knowledge Representation and Reasoning.  The Morgan Kaufmann Series in Artificial Intelligence. Morgan Kaufmann, Amsterdam, 2004.
  * [12] Tom B. Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, Sandhini Agarwal, Ariel Herbert-Voss, Gretchen Krueger, Tom Henighan, Rewon Child, Aditya Ramesh, Daniel M. Ziegler, Jeffrey Wu, Clemens Winter, Christopher Hesse, Mark Chen, Eric Sigler, Mateusz Litwin, Scott Gray, Benjamin Chess, Jack Clark, Christopher Berner, Sam McCandlish, Alec Radford, Ilya Sutskever, and Dario Amodei.  Language models are few-shot learners.  CoRR, abs/2005.14165, 2020.
  * [13] Luca Costabello, Sumit Pai, Chan Le Van, Rory McGrath, Nick McCarthy, and Pedro Tabacof.  AmpliGraph: a Library for Representation Learning on Knowledge Graphs, 2019.
  * [14] Randall Davis, Bruce Buchanan, and Edward Shortliffe.  Production rules as a representation for a knowledge-based consultation program.  Artificial intelligence, 8(1):15–45, 1977.
  * [15] Aldo Gangemi.  Ontology design patterns for semantic web content.  In The Semantic Web–ISWC 2005: 4th International Semantic Web Conference, ISWC 2005, Galway, Ireland, November 6-10, 2005. Proceedings 4, pages 262–276. Springer, 2005.
  * [16] Aldo Gangemi, Nicola Guarino, Claudio Masolo, Alessandro Oltramari, and Luc Schneider.  Sweetening Ontologies with DOLCE, pages 166–181.  Springer, Berlin, Heidelberg, 2002.
  * [17] Thomas Gruber.  A translation approach to portable ontology specifications.  Knowledge Acquisition, pages 199–220, 1993.
  * [18] Nicola Guarino.  Formal ontology and information systems.  In Proceedings of Formal Ontology in Information System, pages 3–15. IOS Press, 1998.
  * [19] Tom Heath and Christian Bizer.  Linked Data: Evolving the Web into a Global Data Space.  Morgan & Claypool, 2011.
  * [20] Pascal Hitzler, Markus Krotzsch, and Sebastian Rudolph.  Foundations of Semantic Web Technologies.  Chapman and Hall/CRC Press, 2010.
  * [21] Aidan Hogan, Eva Blomqvist, Michael Cochez, Claudia d’Amato, Gerard de Melo, Claudio Gutierrez, Sabrina Kirrane, José Emilio Labra Gayo, Roberto Navigli, Sebastian Neumaier, Axel-Cyrille Ngonga Ngomo, Axel Polleres, Sabbir M. Rashid, Anisa Rula, Lukas Schmelzeisen, Juan F. Sequeda, Steffen Staab, and Antoine Zimmermann.  Knowledge graphs.  ACM Comput. Surv., 54(4):71:1–71:37, 2022.
  * [22] Aidan Hogan, Eva Blomqvist, Michael Cochez, Claudia d’Amato, Gerard de Melo, Claudio Gutiérrez, Sabrina Kirrane, José Emilio Labra Gayo, Roberto Navigli, Sebastian Neumaier, Axel-Cyrille Ngonga Ngomo, Axel Polleres, Sabbir M. Rashid, Anisa Rula, Lukas Schmelzeisen, Juan F. Sequeda, Steffen Staab, and Antoine Zimmermann.  Knowledge Graphs.  Number 22 in Synthesis Lectures on Data, Semantics, and Knowledge. Springer, 2021.
  * [23] C. Maria Keet.  An Introduction to Ontology Engineering.  College Publications, 2018.
  * [24] C. Maria Keet and Agnieszka Lawrynowicz.  Test-driven development of ontologies.  In Harald Sack, Eva Blomqvist, Mathieu d’Aquin, Chiara Ghidini, Simone Paolo Ponzetto, and Christoph Lange, editors, The Semantic Web. Latest Advances and New Domains - 13th International Conference, ESWC 2016, Heraklion, Crete, Greece, May 29 - June 2, 2016, Proceedings, volume 9678 of Lecture Notes in Computer Science, pages 642–657. Springer, 2016.
  * [25] Mayank Kejriwal, Craig Knoblock, and Pedro Szekely.  Knowledge Graphs: Fundamentals, Techniques, and Applications.  The MIT Press, 2021.
  * [26] Robert Kowalski.  Logic for Problem Solving, Revisited. Books OnDemand Gmbh, 2014.
  * [27] Robert Kowalski.  Computational Logic and Human Thinking: How to Be Artificially Intelligent. Cambridge University Press, 2010.
  * [28] Markus Krötzsch, František Simančík, and Ian Horrocks.  Description Logics.  IEEE Intelligent Systems, pages 12–19, 2014.
  * [29] Marvin Minsky.  A framework for representing knowledge.  Technical report, USA, 1974.
  * [30] Avanika Narayan, Ines Chami, Laurel J. Orr, and Christopher Ré.  Can foundation models wrangle your data?  Proc. VLDB Endow., 16(4):738–746, 2022.
  * [31] Allen Newell and Herbert Simon.  The logic theory machine–a complex information processing system.  IRE Transactions on information theory, 2(3):61–79, 1956.
  * [32] Ikujirō Nonaka and Hirotaka Takeuchi.  The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation.  Oxford University Press, 1995.
  * [33] Fabio Petroni, Tim Rocktäschel, Sebastian Riedel, Patrick S. H. Lewis, Anton Bakhtin, Yuxiang Wu, and Alexander H. Miller.  Language models as knowledge bases?  In Kentaro Inui, Jing Jiang, Vincent Ng, and Xiaojun Wan, editors, Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing, EMNLP-IJCNLP 2019, Hong Kong, China, November 3-7, 2019, pages 2463–2473. Association for Computational Linguistics, 2019.
  * [34] Richard H Richens.  Preprogramming for mechanical translation.  Mech. Transl. Comput. Linguistics, 3(1):20–25, 1956.
  * [35] Robyn Speer, Joshua Chin, and Catherine Havasi.  Conceptnet 5.5: An open multilingual graph of general knowledge.  In Satinder Singh and Shaul Markovitch, editors, Proceedings of the Thirty-First AAAI Conference on Artificial Intelligence, February 4-9, 2017, San Francisco, California, USA, pages 4444–4451. AAAI Press, 2017\.
  * [36] Mari Carmen Suárez-Figueroa, Asunción Gómez-Pérez, Enrico Motta, and Aldo Gangemi.  Introduction: Ontology engineering in a networked world.  In Mari Carmen Suárez-Figueroa, Asunción Gómez-Pérez, Enrico Motta, and Aldo Gangemi, editors, Ontology Engineering in a Networked World, pages 1–6. Springer, 2012.
  * [37] Thomas Pellissier Tanon, Gerhard Weikum, and Fabian M. Suchanek.  YAGO 4: A reason-able knowledge base.  In Andreas Harth, Sabrina Kirrane, Axel-Cyrille Ngonga Ngomo, Heiko Paulheim, Anisa Rula, Anna Lisa Gentile, Peter Haase, and Michael Cochez, editors, The Semantic Web - 17th International Conference, ESWC 2020, Heraklion, Crete, Greece, May 31-June 4, 2020, Proceedings, volume 12123 of Lecture Notes in Computer Science, pages 583–596. Springer, 2020.
  * [38] Alfred Tarski.  Contributions to the theory of models. I.  Indagationes Mathematicae, 16:572–581, 1954.
  * [39] Michael Uschold.  Demystifying OWL for the Enterprise.  Morgan & Claypool Publishers, 2018.
  * [40] Michael Uschold and Michael Gruninger.  Ontologies: principles, methods and applications.  The Knowledge Engineering Review, pages 93–136, 1996.
  * [41] Denny Vrandečić, Lydia Pintscher, and Markus Krötzsch.  Wikidata: The making of.  In Companion Proceedings of the ACM Web Conference 2023, WWW’23 Companion, page 615–624, New York, NY, USA, 2023. Association for Computing Machinery.
  * [42] Quan Wang, Zhendong Mao, Bin Wang, and Li Guo.  Knowledge graph embedding: A survey of approaches and applications.  IEEE Transactions on Knowledge and Data Engineering, 29(12):2724–2743, 2017.
  * [43] Mark D. Wilkinson., Michel Dumontier, IJsbrand Jan Aalbersberg, Gabrielle Appleton, Myles Axton, Arie Baak, Niklas Blomberg, Jan-Willem Boiten, Luiz Bonino da Silva Santos, Philip E. Bourne, Jildau Bouwman, Anthony J. Brookes, Tim Clark, Mercè Crosas, Ingrid Dillo, Olivier Dumon, Scott Edmunds, Chris T. Evelo, Richard Finkers, Alejandra Gonzalez-Beltran, Alasdair J.G. Gray, Paul Groth, Carole Goble, Jeffrey S. Grethe, Jaap Heringa, Peter A.C ’t Hoen, Rob Hooft, Tobias Kuhn, Ruben Kok, Joost Kok, Scott J. Lusher, Maryann E. Martone, Albert Mons, Abel L. Packer, Bengt Persson, Philippe Rocca-Serra, Marco Roos, Rene van Schaik, Susanna-Assunta Sansone, Erik Schultes, Thierry Sengstag, Ted Slater, George Strawn, Morris A. Swertz, Mark Thompson, Johan van der Lei, Erik van Mulligen, Jan Velterop, Andra Waagmeester, Peter Wittenburg, Katherine Wolstencroft, Jun Zhao, and Barend Mons.  The FAIR Guiding Principles for scientific data management and stewardship.  Scientific data, pages 1–9, 2016.