%+
%   TITLE:          OWLschemafy_V_2_002.tex
%   VERSION:        2-002
%   FACILITY:       entry point of the paper OWLschemafy
%
%                   OWLschemafy presents a streamlined ontology development
%                   approach through a user-friendly text-based interface.
%                   This application extracts its operational directives
%                   from the user-generated text files, fostering the creation
%                   of OWL/XML encoded ontologies. Furthermore, OWLschemafy
%                   integrates with the Prot\'{e}g\'{e} Ontology Editor, permitting
%                   users to capitalize on the strengths of both applications.
%                   Notably, this application functions as a front end for the
%                   Prtege Ontology Editor.
%
%   AUTHOR(S):      Hlaszny, Edit PhD [HED] edithlaszny@gmail.com
%   SUPERVISED BY:  -
%   CREATION DATE:  18-JUL-2024
%
%   ENVIRONMENT:    TeXstudio 4.8.1
%                   on iMAC macOS Monterey Version 12.5.1
%
%   DESIGN ISSUES:  LaTeX Beginners Guide.pdf
%                   LaTex manual.pdf
%                   Practical Guide for Scientific Writing.pdf
%                   Practical LaTeX.pdf
%                   TeXStudioAnleitung.pdf
%                   The LaTeX companion.pdf
%
%   PORTABILITY ISSUES:     none
%   SUBSYSTEM:              none
%   MODIFICATION HISTORY:
%       date        modified by  vers.
%       23-JUL-2024 [HED]        1-001 first draw
%       30-JUL-2024 [HED]        2-001 layout changed
%       13-SEP-2024 [HED]        2-001 new domain: edithlaszny.eu
%       29-SEP-2024 [HED]        2-002 widow control cosmetics
%-

\documentclass[8pt]{article}

\usepackage{multicol}
\usepackage{graphicx}
\usepackage{graphics}
\usepackage{fancyhdr}
\usepackage{geometry}
\usepackage{caption}
\usepackage{xcolor}
\usepackage{hyperref}
\usepackage{enumerate}
\usepackage{float}
\usepackage{multicol,caption}
\usepackage{multicol}
\usepackage[T1]{fontenc}

%+
%  Supressing the package warning:
%  <The option 'hypcap=true' will be ignored>
%-
\captionsetup{hypcap=false}

%+
%   two column document, with column separation
%-
\setlength{\columnsep}{20pt}

\hoffset         = -30pt
\voffset         =   0pt
\headheight      =  10pt
\headsep         =  26pt
\textheight      = 660pt
\footskip        =  35pt
\textwidth       = 495pt
\paperwidth      = 595pt
\paperheight     = 842pt

\pagestyle{fancy}
\fancyhead[L]{\scriptsize{OWLschemafy -- A Java-based, Text-Driven
                          Ontology Generator for Streamlined OWL}}
\fancyfoot[L]{\textcolor[RGB]{160,160,160}{\scriptsize{\raise0.3ex\hbox{\tiny{\textcopyright}}Edit
              Hlaszny, PhD | 29 September 2024}}}
\fancyfoot[C]{ }
\fancyfoot[R]{\scriptsize{Page \thepage}}

\newenvironment{myindentpar}[1]%
{   \begin{list}{}%
         {\setlength{\leftmargin}{#1}}%
         \item[]%
    }
    {\end{list}
 }

%+
%  Customized item list
%  #1 : item entry
%  #2 : item content
%-
\newcommand{\piece}[2]{
    \item{\emph{#1} {#2}}
}

%+
%  Customized item list
%  #1 : item
%-
\newcommand{\densepiece}[1]{
    \item{#1}
    \vspace{-6pt}
}

%+
%  Defining macro for unique figure-displaying
%  #1 : filename of the figure
%  #2 : width (0.5 .. 1.0)
%  #3 : figure title
%  #4 : indentation (\raggedleft, \raggedright, \centering)
%  #5 : +/- vertical space before the figure
%  #6 : +/- vertical space between the figure and the title
%  #7 : +/- vertical space after the figure
%-
\newcommand{\showFig}[7]{
    \vspace{#5} % space before
    \captionsetup{labelfont={sf}}
    \medskip
        \noindent
        \begin{minipage}{\columnwidth}
            #4  %  indentation
            \includegraphics[width=#2\columnwidth]{#1} % figure filename
            \vspace{#6}
            \captionof{figure}{\fontsize{9}{9}\selectfont\sffamily #3} % figure title
        \end{minipage}
    \medskip
    \vspace{#7} % space after
}

\title
{
    \fontsize{12pt}{12pt}\selectfont\sffamily
    \hspace{-20pt}
    \textbf{OWLschemafy -- A Java-based, Text-Driven Ontology Generator for Streamlined OWL}
    \par
    \vspace{12pt}
}

\author % and Abstract
{
    \fontsize{10pt}{10pt}\selectfont\sffamily
    \hspace{-18pt}
    Edit Hlaszny, PhD\\
    Dr Hlaszny Bioystems Engineering\\
    Mail: edit@edithlaszny.eu\\
    \hypersetup{hidelinks}\url{http://www.edithlaszny.eu/}\\
    Phone: +36 30 3116516
    \fontsize{10pt}{10pt}\selectfont\sffamily
    \\ \\ \textbf{Abstract}
    \vspace{4pt}\\
    \fontsize{8pt}{8pt}\selectfont\sffamily
    OWLschemafy presents a streamlined ontology development approach through
    a user-friendly text-based interface. This application extracts its
    operational directives from the user-generated text files, fostering
    the creation of OWL/XML encoded ontologies. Furthermore, OWLschemafy
    integrates with the Prot\'{e}g\'{e} Ontology Editor, permitting users to
    capitalize on the strengths of both applications.
    \vspace{8pt}\\
    \fontsize{10pt}{10pt}\selectfont\sffamily
    \textbf{Keywords}
    \vspace{4pt}\\
    \fontsize{8pt}{8pt}\selectfont\sffamily
    Ontology; OWL generator; front end for Prot\'{e}g\'{e}; Java-based
    application.
}

%+
%   BEGIN DOCUMENT  ---------------------------------------------------------------------
%-
\begin{document}

\makeatletter
    \@title
    \@author
\makeatother

%+
%   BEGIN OF TWO COLUMNS   --------------------------------------------------------------
%-
\begin{multicols}{2}

%+
%   Setting the layout of SECTIONS   ----------------------------------------------------
%-
\renewcommand{\section}[1]
{
    \vspace{4pt}
    \setcounter{secnumdepth}{0} % Suppress numbering for all sections
    \fontsize{10}{10}\selectfont\sffamily
    \label{#1}
    \par
    \nobreak
    \vskip 0.3\baselineskip\noindent
    \vspace{-10pt}\hspace{-8pt}
    \refstepcounter{section}
    {\normalfont\arabic{section}.}~\ignorespaces
    \textbf{#1}
    \addcontentsline{toc}{section}{#1}
    \vspace{6pt}
}

%+
%   Setting the layout of SUBSECTIONS   ------------------------------------------------
%-
\renewcommand{\subsection}[1]
{
    \fontsize{9}{9}\selectfont\sffamily\parindent=0pt
    \label{#1}\par\nobreak % Don't break before title on a new page
    \refstepcounter{subsection}
    \vskip 0.8\baselineskip
    \noindent
    {\normalfont\arabic{section}.\arabic{subsection}}~
    #1
    \par
    \addcontentsline{toc}{subsection}{#1}
    \vspace{4pt}
}

%+
%   Setting the layout of SUBSECTIONS   ------------------------------------------------
%-
\renewcommand{\subsubsection}[1]
{
    \fontsize{9}{9}\selectfont\sffamily\parindent=0pt
    \label{#1}\par\nobreak
    \vskip 0.4\baselineskip
    \emph{#1}
    \par
    \addcontentsline{toc}{subsection}{#1}
    \vspace{2pt}
}

%+
%   New Section  1
%-
\section
{Introduction}

    \subsection
    {Ontologies: The Bedrock Of Knowledge Representation} % 1.1
    In the ever-expanding digital landscape, the ability to effectively organize and represent
    knowledge is paramount\raise0.8ex\hbox{\tiny{ [5][7]}}. Ontologies play a
    critical role in this endeavor, acting as formal specifications of a domain's concepts, properties, and
    relationships. The importance of ontologies lies in their ability to:

        \subsubsection
        {Standardize Knowledge Representation:}
        Ontologies provide a common vocabulary and structure for describing entities within a
        domain\raise0.8ex\hbox{\tiny{ [9]}}. This enhance clear communication
        and reduces ambiguity when dealing with complex knowledge.

        \subsubsection
        {Enable Knowledge Sharing and Reuse:}
        By establishing a shared understanding, ontologies facilitate the seamless exchange of
        knowledge between different systems and applications. Existing ontologies can be reused
        and extended, promoting efficiency and avoiding the duplication of effort.

        \subsubsection
        {Support Reasoning and Inference:}
        Ontologies encode logical relationships between
        concepts, enabling machines to perform automated reasoning and draw inferences
        from the encoded knowledge. This capability underpins various applications, such
        as information retrieval, decision support systems, and knowledge base
        completion\raise0.8ex\hbox{\tiny{ [9]}}.

    \subsection
    {Challenges In Traditional Ontology Development} %1.2

        Despite their undeniable benefits, traditional ontology development methods often face
        several challenges:

        \subsubsection
        {Knowledge Acquisition Bottleneck:}
        The initial process of identifying, defining, and formalizing domain knowledge can be
        time-consuming and resource-intensive. This "knowledge acquisition bottleneck" presents
        a significant hurdle in ontology development.

        \subsubsection
        {Limited User-Friendliness:}
        Traditional methods often rely on specialized tools and expertise, making them less
        accessible to users without a background in ontology
        engineering\raise0.8ex\hbox{\tiny{ [2]}}.

        \subsubsection
        {Scalability Issues:}
        As ontologies grow in size and complexity, managing and maintaining them using
        traditional methods can become increasingly difficult.
    \vspace{4pt}\\
    These challenges highlight the need for innovative approaches that streamline the
    ontology development process, increase userfriendliness, and ensure scalability for
    larger knowledge structures.

%+
%   New Section 2
%-
\section
{OWLschemafy Is User-Centric}

    \subsection
    {Embracing Text-Driven Control For Streamlined Owl Development} % 2.1
    Traditional ontology development methods often involve intricate tools and knowledge of
    ontology languages like OWL (Web Ontology Language). This chapter introduces OWLschemafy,
    a text-driven ontology generator that empowers users to create OWL ontologies through a
    user-friendly and intuitive interface text files.

    \subsection
    {The Power Of Text-Based Control} % 2.2
    OWLschemafy leverages the flexibility and accessibility of text files to provide users
    with granular control over the ontology generation process. These text files act as the
    building blocks for constructing OWL ontologies, specifying various elements through
    a clear and concise syntax. The key advantages of using text files for ontology control
    include

        \subsubsection
        {Enhanced Readability and Editability:}
        Text files are readily human-readable and editable using any basic text editor.
        This user-friendliness lowers the barrier to entry for ontology development,
        making it accessible to a broader range of users without requiring specialized
        knowledge of OWL syntax.

        \subsubsection
        {Flexibility and Customization:}
        Text files offer a high degree of flexibility in specifying the ontology structure
        and content. Users can tailor the control files to their specific needs, defining
        elements like classes, properties, and relationships in a way that aligns with their
        understanding of the domain.

        \subsubsection
        {Version Control and Collaboration:}
        Text files are inherently version-controllable, enabling users to track changes and
        revert to previous versions if necessary. This feature facilitates collaboration,
        allowing multiple users to work on the same ontology by editing and sharing the
        control files.

    \subsection
    {Demystifying The Control File Structure} % 2.3
    OWLschemafy employs a well-defined structure within the text files to capture the
    various components of an OWL ontology\raise0.8ex\hbox{\tiny{ [7]}}. Key
    elements specified in these files include

        \subsubsection
        {OWL Class Structure:}
        The hierarchical structure of classes within the ontology is defined using indentation.
        Each level of indentation represents a subclass relationship, adhering to the tab-based
        indentation convention compatible with Prot\'{e}g\'{e}, a widely used ontology editor.

        \subsubsection
        {Class Disjointness Definitions:}
        These files allow users to specify classes that are mutually exclusive, ensuring that
        no individual can belong to both classes simultaneously.

        \subsubsection
        {Class-Individual Definitions:}
        Individuals, representing specific instances within a class, are defined using text
        files. These definitions can include data property values and object property
        relationships, linking individuals to other entities within the ontology.

        \subsubsection
        {Entity Annotations:}
        OWLschemafy empowers users to attach annotations to various entities (classes,
        individuals, properties) within the ontology. These annotations enrich the ontology
        with additional information, such as comments, definitions, or references to external
        resources.

        \subsubsection
        {Triplet Generation:}
        Arguably the most crucial aspect of the control files lies in their ability to
        define triplets. Triplets, the fundamental building blocks of OWL ontologies,
        represent relationships between entities. Text files specify these triplets,
        dictating how classes, properties, and individuals are interconnected.
    \vspace{4pt}\\
    By leveraging this intuitive text-based approach, OWLschemafy empowers users to
    construct rich and expressive OWL ontologies without grappling directly with the
    complexities of OWL syntax. The following sections will delve deeper into
    the core functionalities of OWLschemafy, outlining how it streamlines the ontology
    development process for users of all backgrounds.

%+
%   New Section 3
%-
\section
{OWLschemafy is Text-Driven}

    \subsection
    {Enhancing User-Centricity With Text-File Control} % 3.1

    This chapter seeks into the core functionalities of OWLschemafy,
    highlighting its innovative approach to ontology development. OWLschemafy departs
    from the traditional paradigm of directly writing OWL code, instead leveraging
    the user-friendliness and accessibility of text files as the primary control
    mechanism. This user-centric design philosophy empowers researchers and developers
    to construct OWL ontologies through an intuitive and streamlined process.
    \vspace{4pt}\\
    The Figure 1. below visually portrays the interplay between OWLschemafy
    and Prot\'{e}g\'{e}.

    \showFig{./pictures/Fig_1.png}  % filename to be displayed
            {1.0}                   % width
            {OWLschemafy as front end to Prot\'{e}g\'{e}.} % title
            {\raggedright}          % indentation
            {2pt}                   % space before
            {-10pt}                 % space between figure and title
            {-2pt}                  % space after

    OWLschemafy acts as a front end, utilizing user-provided text files to
    generate OWL/XML encoded ontologies: These generated ontologies can then be seamlessly
    imported and further refined within the familiar environment of Prot\'{e}g\'{e}, a
    widely adopted ontology editor\raise0.8ex\hbox{\tiny{ [6][10]}}.

    \subsection
    {Key Functionalities For Streamlined Development} % 3.2
    OWLschemafy offers a comprehensive suite of functionalities geared towards
    streamlining the ontology development lifecycle. Here's a glimpse into some
    of its key features:

%+
%   New Section 4
%-
\section
{Key Functionalities Of OWLschemafy}

    \subsection % 4.1
    {Text-File Driven Control -- A User-Friendly Interface Vs. Its Difficulties}
    OWLschemafy's cornerstone lies in its text-file driven control mechanism.
    Users create and edit text files with a well-defined structure, specifying
    the various components of the ontology. However, the difficulties arising from
    the use of text files cannot be ignored, such as

        \subsubsection
        {Scalability:}
        As ontologies grow larger and more complex, text-based control
        files can become cumbersome to manage. Maintaining consistency
        and tracking changes across numerous files can be challenging.

        \subsubsection
        {Error-prone:}
        Manually editing text files increases the risk of introducing
        errors during definition or modification. Version control becomes
        crucial for managing changes and reverting to previous states.

        \subsubsection
        {Limited Functionality:}
        Text files offer limited functionalities for complex control structures
        or advanced operations. Complex logic or dependencies within the control
        flow might be difficult to represent effectively.

        \subsubsection
        {Querying and Analysis:}
        Analyzing and querying information within the control files can be
        challenging. Extracting specific details or performing comparisons
        across different files requires manual effort or custom scripting.

    \subsection % 4.2
    {Controlling Ontology Generation With Text Files In OWLschemafy}
    OWLschemafy uses five distinct text files to exert granular control
    over the ontology generation process. These files address specific
    aspects of the ontology structure and content, adhering to a
    well-defined sequence that mirrors the ontology's construction.

        \subsubsection
        {Ontology Header File:}
        The initial text file defines the header information for the generated
        ontology, including essential metadata elements.

        \subsubsection
        {OWL Class Structure File:}
        This file specifies the hierarchical organization of classes within
        the ontology. A well-defined indentation scheme, often adhering to
        tab-based conventions for compatibility with Prot\'{e}g\'{e}, represents
        subclass relationships.

        \subsubsection
        {Class Disjointness File:}
        OWLschemafy enables the specification of disjoint classes through a
        dedicated text file. Disjoint classes are mutually exclusive categories,
        ensuring that no individual can belong to both classes simultaneously.

        \subsubsection
        {Class Annotation File:}
        Annotations enrich the ontology by providing additional
        information about classes, such as definitions, comments,
        or references to external resources. A dedicated text file
        facilitates the incorporation of such annotations.

        \subsubsection
        {Triplet Definition File:}
        Arguably the most intricate aspect of ontology
        development lies in defining triplets, the fundamental building blocks that
        express relationships between entities. The final text file within
        OWLschemafy's control mechanism caters to this critical task. It encompasses
        not only the specification of triplets but also the creation of the necessary
        named individuals, the object-, and data-properties that participate in these
        relationships.
    \vspace{4pt}\\
    This sequential order of text file processing reflects the step-by-step
    construction of the ontology itself. By meticulously crafting these
    control files, users empower OWLschemafy to generate ontologies tailored
    to their specific needs \raise0.8ex\hbox{\tiny{ [1]}}.

    \subsection % 4.3
    {Streamlined OWL/XML Generation -- Automation For Efficiency}
    Once users have meticulously crafted their control files, the OWLschemafy
    automates the generation of OWL/XML encoded ontologies. This automation
    significantly reduces the time and effort required for ontology development
    compared to manual OWL code writing. The core functionalities involved in
    the generation process include:

        \subsubsection
        {Parsing Control Files:}
        OWLschemafy parses the user-provided text files, extracting the specified
        ontology elements and their relationships.

        \subsubsection
        {Generating OWL/XML Syntax:}
        Based on the parsed information, OWLschemafy translates the extracted
        elements and relationships into the corresponding OWL/XML syntax,
        adhering to the OWL standard.

        \subsubsection
        {Validation and Error Checking:}
        OWLschemafy incorporates functionalities to validate the user-provided
        information within the control files. This ensures that the generated
        OWL/XML output adheres to the OWL syntax and avoids potential errors.

    \subsection % 4.4
    {Prot\'{e}g\'{e} Integration -- A Synergistic Workflow}
    OWLschemafy empowers a synergistic workflow by seamlessly integrating with
    Prot\'{e}g\'{e}, a widely adopted ontology editor. This integration offers several
    benefits:

        \subsubsection
        {Leveraging Prot\'{e}g\'{e}'s Visual Editing Capabilities:}
        The generated OWL/XML ontologies can be effortlessly imported into Prot\'{e}g\'{e}.
        Once imported, users can inflict Prot\'{e}g\'{e}'s visual editing interface to
        further refine and edit the ontology structure. This visual representation
        can be particularly helpful for complex ontologies.

        \subsubsection
        {Comprehensive Ontology Management:}
        Prot\'{e}g\'{e} offers a suite of functionalities for managing ontologies,
        including support for reasoning, version control, and collaboration.
        This integration allows users to seamlessly switch between text-based
        control in OWLschemafy and Prot\'{e}g\'{e}'s comprehensive ontology management
        environment.

    \subsection % 4.5
    {Prot\'{e}g\'{e}'s Functionalities Complementing OWLschemafy's Workflow}
    While OWLschemafy acts as a user-centric front end for ontology
    development, its efficacy is significantly amplified when coupled
    with the comprehensive functionalities offered by Prot\'{e}g\'{e}, a widely
    adopted ontology editor. Prot\'{e}g\'{e} provides a rich set of features
    that seamlessly integrate with OWLschemafy's output, empowering
    users to further refine, analyze, and manage their ontologies.

        \subsubsection
        {Reasoning Capabilities:}
        Prot\'{e}g\'{e} integrates several reasoners out-of-the-box, including ELK
        0.5.0, Fact++ 1.6.5, and HermiT 1.4.3.456. These reasoners enable
        users to assess the logical consistency and infer implicit knowledge
        within their ontologies, facilitating the creation of robust and
         well-founded knowledge structures.

        \subsubsection
        {Visualization and Navigation:}
        Prot\'{e}g\'{e}'s OntoGraf plugin facilitates the visualization of specific
        ontology subgraphs, allowing users to focus on intricate portions
        of the knowledge structure. Additionally, the OWLViz plugin
        empowers users to navigate and explore class hierarchies within
        the ontology.

        \subsubsection
        {Querying and Export:}
        Prot\'{e}g\'{e} offers a SPARQL query engine, enabling users to formulate
        queries and retrieve specific information from the ontology. This
        capability fosters in-depth exploration and analysis of the
        encoded knowledge.
        \vspace{4pt}\\
        Leveraging these complementary functionalities within Prot\'{e}g\'{e}, users
        can effectively extend the capabilities of OWLschemafy, enriching the
        ontology development process and empowering the creation of comprehensive
        and well-reasoned knowledge structures.

        \subsubsection
        {Intuitive Text-File Based Control:}
        As mentioned earlier, OWLschemafy leverages text files for user control.
        These files house detailed specifications for the ontology structure,
        including classes, properties, relationships, and annotations. The
        straightforward syntax employed within the text files makes them readily
        understandable and editable using standard text editors.

        \subsubsection
        {Streamlined OWL/XML Generation:}
        Once users have meticulously crafted their control files, OWLschemafy
        automates the generation of OWL/XML encoded ontologies. This automation
        significantly reduces the time and effort required for ontology development
        compared to manual OWL code writing.

        \subsubsection
        {Protege Integration: }
        OWLschemafy supports a synergistic workflow by seamlessly integrating with
        Prot\'{e}g\'{e}. The generated OWL/ XML ontologies can be effortlessly imported
        into Prot\'{e}g\'{e}, allowing users to take advantage its visual editing
        capabilities and comprehensive ontology management functionalities.
    \vspace{4pt}\\
    By harnessing these core functionalities, OWLschemafy empowers users to
    construct OWL ontologies with greater efficiency, flexibility, and
    user-friendliness. The subsequent sections will delve deeper into specific
    functionalities, illustrating how OWLschemafy simplifies various aspects
    of the ontology development process.

%+
%   New Section 5
%-
\section
{Technical Details And Implementation}

    \subsection
    {Beyond Functionality: A Deep Dive}
    This paper investigates beyond introducing a novel front end for
    Prot\'{e}g\'{e}.
    It offers a comprehensive technical description, meticulously detailing
    the control files (user interaction building blocks) and the core Java
    source code. Detailed JavaDoc documentation further enhances understanding
    and future development.
    \vspace{4pt}\\
    This transparency empowers researchers and developers to replicate
    the software and contribute to its growth. The readily available JavaDoc
    streamlines future modifications and reduces the learning curve.
    \vspace{4pt}\\
    By extending its scope, this paper establishes a strong foundation
    for further exploration and development of this technical framework.
    \vspace{4pt}\\
    To showcase the capabilities of OWLschemafy, this chapter looks
    into modeling a relatively simple and well-defined, compact (that is
    bounded and closed :) domain: the PRINCE2 Project Management System.
    Effectively modeling a technical subject area necessitates three key elements:
    \begin{itemize}
        \piece{In-depth Domain Knowledge:}
              {A comprehensive understanding of
              the chosen domain is essential.}
        \piece{Modeling Expertise:}
              {A solid grasp of modeling principles
              and methodologies is crucial.}
        \piece{Suitable Modeling Tool:}
              {The selection and proficient use of an
              appropriate modeling tool streamlines the process.}
    \end{itemize}
    Here, we focus on the third element, specifically the Prot\'{e}g\'{e} ontology
    editor enhanced by OWLschemafy, the front-end tool introduced in this paper.

    \subsection
    {Ontology Design Considerations}

    Developing ontologies necessitates careful consideration of several
    key principles:

        \subsubsection
        {Top-Down Approach: }
        Ontologies adhere to a top-down design philosophy, commencing with a
        conceptualization of the domain and progressing towards the electronic
        management and storage of information.

        \subsubsection
        {Reusability and Interoperability:}
        A well-designed ontology should promote reusability across diverse
        domains. For instance, the generated OWL file can be seamlessly integrated
        into a SPARQL-enabled graph database (e.g. Nebugraph, Neo4j, Ontotext
        GraphDB, or Oracle RDF Graph; part of Oracle Database), fostering
        interoperability and knowledge exchange\raise0.8ex\hbox{\tiny{ [3][4]}}.
        Ontotext GraphDB can directly load the generated OWL/XML encoded ontology.

        \subsubsection
        {Accommodating Domain Growth:}
        The ontology should be adaptable to accommodate the influx of new
        information continuously generated within the domain it represents. This
        ensures the ontology's continued relevance and utility over time. A
        flexible ontology structure, accompanied by clear extension mechanisms,
        is essential for managing domain growth without compromising the ontology's
        integrity.

        \subsubsection
        {Preserving Existing Synergies:}
        Maintaining and potentially expanding established synergies and
        interfaces with other tools is crucial. This facilitates a more
        integrated knowledge management ecosystem.

    \subsection
    {Ontology Header Specification}
    An ontology typically commences with a standardized header. This header
    incorporates essential information such as the XML version, xmlns
    definitions, prefix names, and annotations. Common annotations include
    dc:title, dc:author, dc:date, and other DCMI metadata terms, such as
    language, contributor, version, phone number.
    \vspace{4pt}\\
    OWLschemafy uses a dedicated control file, \texttt{P2\char`_HeaderDef.txt}
    the content of this control file, which consists of \texttt{IRI} and
    \texttt{LITERAL} pairs. Empty lines and lines starting with "!" are ignored
    by OWLschemafy. "!" allows for comments within the files.
    \vspace{4pt}\\
    The ontology header specificationsis depicted on the Figure 2.

   \showFig{./pictures/Fig_2.png}   % filename to be displayed
            {1.0}                   % width
            {Ontology header definition.} % title
            {\raggedright}          % indentation
            {2pt}                   % space before
            {-14pt}                 % space between figure and title
            {-2pt}                  % space after
    \vspace{4pt}\\

    OWLschemafy translates the content of the aforementioned control file into
    the following OWL code snippet on Figure 3.

    \showFig{./pictures/Fig_3.png}  % filename to be displayed
            {1.0}                   % width
            {Genereated OWL/XML code as ontology header by OWLschemafy.} % title
            {\raggedright}          % indentation
            {2pt}                   % space before
            {-14pt}                 % space between figure and title
            {-6pt}                  % space after

    Figure 4. showcases the OWL/XML encoded code displayed within the Prot\'{e}g\'{e}
    environment. While the default order of generated OWL ontology items in
    Protégé does not match the original ontology header, this behavior can be modified
    to reflect the sequence of scanned header items.

    \showFig{./pictures/Fig_4.png}  % filename to be displayed
            {1.0}                   % width
            {Ontology header displayed in Prot\'{e}g\'{e}.} % title
            {\raggedright}          % indentation
            {2pt}                   % space before
            {-14pt}                 % space between figure and title
            {-2pt}                  % space after

    \subsection
    {Controlled Vocabulary And Class Definition:}
    The practical process of ontology construction often begins with
    the creation of a simplified vocabulary. The simplified vocabulary
    (Figure 5) serves as the definitive foundation for an ontology because
    it establishes the core building blocks for representing knowledge
    within a specific domain.
    \vspace{4pt}\\
    It defines the essential concepts, their relationships, and the
    attributes that describe them. Just as a building relies on a
    strong foundation, a robust and well-defined simplified vocabulary
    ensures the clarity, interoperability, and reasoning capabilities
    of an ontology.

    \showFig{./pictures/Fig_5.png}  % filename to be displayed
            {0.8}                   % width
            {Simplified PRINCE2 Vocabulary.} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-6pt}                  % space between figure and title
            {-2pt}                  % space after

    Prot\'{e}g\'{e} uses a well-defined tab-based indentation scheme to represent class
    hierarchies, a convention that OWLschemafy faithfully preserves. From the
    tab-delimited control file (\texttt{P2\char`_classStructure.txt}) illustrates a
    part the Figure 6. This preservation facilitates direct comparison within Prot\'{e}g\'{e},
    particularly for intricate or ambiguous class relationships.

    \showFig{./pictures/Fig_6.png}  % filename to be displayed
            {0.6}                   % width
            {Tab-indented configuration file defines the class-structure of the ontology.} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-6pt}                  % space between figure and title
            {-2pt}                  % space after

    \showFig{./pictures/Fig_7a.png} % filename to be displayed
            {1.0}                   % width
            {Class-structure in the ontology generated by OWLschemafy.} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-6pt}                  % space between figure and title
            {-2pt}                  % space after

    \showFig{./pictures/Fig_7b.png} % filename to be displayed
            {1.0}                   % width
            {Subclass definitions in the ontology generated by OWLschemafy.} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-6pt}                  % space between figure and title
            {-2pt}                  % space after

    \showFig{./pictures/Fig_8.png}  % filename to be displayed
            {0.7}                   % width
            {Class-structure in Prot\'{e}g\'{e}.} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-6pt}                  % space between figure and title
            {-2pt}                  % space after

    Figures 10, 11, and 12 illustrate the relationship between the class
    annotations contained control file \texttt{P2\char`_classAnnotation.txt}, the
    corresponding OWL/XML code snippet generated by OWLschemafy, and the
    resulting visualized within Prot\'{e}g\'{e}:

    \showFig{./pictures/Fig_9.png}  % filename to be displayed
            {1.0}                   % width
            {Class annotation definition in the control file.} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-6pt}                  % space between figure and title
            {-2pt}                  % space after

    \showFig{./pictures/Fig_10.png} % filename to be displayed
            {1.0}                   % width
            {Generated class annotation in the generated {\tt .owl} file.} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-6pt}                  % space between figure and title
            {-2pt}                  % space after

    \showFig{./pictures/Fig_11.png} % filename to be displayed
            {1.0}                   % width
            {Class annotation displayed in Prot\'{e}g\'{e}.} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-6pt}                  % space between figure and title
            {-2pt}                  % space after

    \subsection
    {Disjoint Classes In Ontologies}
    There are several key considerations when determining whether to define
    classes as disjoint.

        \subsubsection
        {Mutual Exclusivity and Domain Specificity:}
        The primary consideration is whether membership in one class inherently
        eliminates the possibility of belonging to the other. The decision to
        make classes disjoint can be domain-specific.

        \subsubsection
        {Reasoning and Inference:}
        Declaring classes as disjoint can enhance the reasoning capabilities of
        an ontology. By explicitly stating that certain classes are mutually
        exclusive, the ontology reasoner can identify inconsistencies and draw
        more accurate inferences based on the encoded knowledge.
        \vspace{4pt}\\
        OWLschemafy facilitates the definition of disjoint classes through a
        dedicated control file. This file explicitly specifies which classes
        within the ontology should be mutually exclusive. Figures 13, 14, and
        15 illustrate the interrelated aspects of this process: the control file
        (\texttt{P2\char`_DisjointClassDefs.txt})
        containing the disjoint class definitions, the corresponding OWL/XML
        code snippet generated by OWLschemafy based on these definitions, and
        the resulting visualization within Prot\'{e}g\'{e}'s DL Class Axiom Renderer.

        \subsubsection
        {Ontology Structure and Maintainability:}
        This is a crucial factor when deciding on disjoint classes. The
        ontology designer should be carefully considered how disjoint
        classes impact the overall ontology structure, how can enhance
        maintainability and prevent inconsistencies.

        \showFig{./pictures/Fig_12.png}  % filename to be displayed
            {0.6}                   % width
            {Disjoint class definitions in the control file.} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-6pt}                  % space between figure and title
            {-2pt}                  % space after

        \showFig{./pictures/Fig_13.png}  % filename to be displayed
            {1.0}                   % width
            {Generated disjoint class definitions in\\ the result {\tt .owl} file.} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-6pt}                  % space between figure and title
            {-2pt}                  % space after

        \showFig{./pictures/Fig_14.png}  % filename to be displayed
            {1.0}                   % width
            {Disjoint classes' visualization within
             Prot\'{e}g\'{e}'s\\ DL Class Axiom Renderer.} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-6pt}                  % space between figure and title
            {-2pt}                  % space after
%+
%   New Section 6
%-
\section
{Triplet Definitions In OWLschemafy}
\vspace{12pt}\\
    The Prot\'{e}g\'{e} front end OWLschemafy employs a specific format
    (\texttt{P2\char`_tripletDefs.txt}) for defining triplets (subject,
    predicate, and object), which represent relationships between entities
    within the ontology in which the following elements are involved:

    \subsection
    {Comments and Separators:}
    Lines in each control files starting with "!+" and "!-" are comments (or
    even block comments, which can be extracted as a whole) used to enhance
    readability and separate sections within the definition.
    Empty lines will also be negligated.

    \subsection
    {Triplet Set:}
    The definition starts with \texttt{START\char`_OF\char`_TRIPLE\char`_SET}
    and ends with \texttt{END\char`_OF\char`_TRIPLE\char`_SET}, demarcating the entire set of
    triplets being defined.

    \subsection
    {Header Section:}
    \texttt{START\char`_OF\char`_HEADER} and \texttt{END\char`_OF\char`_HEADER}:
    these markers enclose the header information for the triplet set. This header defines various properties
    associated with the relationships specified in the triplets.
    \vspace{4pt}\\
    \texttt{PREDICATE\char`_NAME} and \texttt{INV\char`_PREDICATE\char`_NAME}:
    These define the object property names used to represent the relationship in both directions. For example,
    \texttt{documentCreatedBy} and \texttt{createsDocument} represent the
    relationship between a Document and an Actor (who created it).
    \vspace{4pt}\\
    \texttt{SUPER\char`_OBJECT\char`_PROPERTY}: This specifies the superclass of
    the object property in the OWL hierarchy (e.g., owl:topObjectProperty).

    \subsection
    {Triplet Definitions:}
    This section defines the actual relationships between entities.
    Figure 16. shows a triplet set. Each line after the triplet set
    header (from the line 925) represents a single triplet.

    \showFig{./pictures/Fig_15.png} % filename to be displayed
            {1.0}                   % width
            {Triplet Set Definitions.} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-6pt}                  % space between figure and title
            {-2pt}                  % space after

    \begin{itemize}
        \piece{Subject and Object:}
             {These represent the OWL class-instances (individuals) of the
             classes participating in the relationship.}
        \piece{Data Property Values:}
             {Following the subject and object, there can be additional
              values associated with the data properties defined in the
              header.}
        \piece{Class individuals:}
             {OWLschemafy can automatically generate class individuals
              (e.g., with sequential numbering) when triplets are defined.
              This eliminates the need to predefine every single instance
              within the ontology.}
        \piece{Data properties:}
             {are also generated based on the information provided in the
              triplet set header. This streamlines the definition process.}
    \end{itemize}

    Overall, triplet definitions in OWLschemafy offer a concise and
    efficient way to specify relationships and their associated
    data properties within an ontology. The header section provides
    context and meaning for the relationships, while the individual
    triplets establish the specific instances and their corresponding
    values according the OWL language definitions\raise0.8ex\hbox{\tiny{ [7]}}.

    \subsection
    {Steps Containing Triplet Set Definitions:}
    The following ten steps are needed to define triplets
    \begin{enumerate}
        \piece{Object Property Declaration:}
              {OWLschemafy declares two object properties based on the information
              in the header. The first property represents the primary direction of
              the relationship, and the second property represents its inverse.}
        \piece{Inverse Object Property Relationship:}
              {OWLschemafy establishes that the two declared object properties are
              inverses of each other. This ensures that the relationship can be
              navigated in both directions within the ontology.}
        \piece{Object Property Annotations:}
              {OWLschemafy incorporates human-readable annotations for both object
              properties. These annotations provide context and clarify the meaning
              of the relationships being defined.}
        \piece{Super Object Property:}
              {OWLschemafy assigns a superclass (e.g., \texttt{owl:topObjectProperty})
              to the declared object properties within the OWL hierarchy. This helps
              categorize and organize the properties within the ontology.}
        \piece{Subject and Object Class Individuals:}
              {OWLschemafy can automatically generate instances (individuals) of the
              classes participating in the relationship. These instances represent
              specific entities within the domain.}
        \piece{Data Property Declaration:}
              {OWLschemafy declares data properties associated with the subject and
              object of the relationship. These properties provide additional details
              or attributes about the entities involved.}
        \piece{Data Property Annotations:}
              {Similar to object properties, annotations are added to data properties
              to explain their purpose and meaning.}
        \piece{Super Data Property:}
              {A superclass (e.g.\\
              \texttt{owl:topDataProperty}) is assigned to
              the data properties within the OWL hierarchy for organization.}
        \piece{Connecting Data Properties and Individuals:\\}
              {OWLschemafy establishes connections between the data properties and
              the class individuals participating in the relationship. This allows
              associating specific values with the entities.}
        \piece{Triplet Definition:}
              {Finally, OWLschemafy defines the actual triplets based on the object
              properties and the class individuals. Each triplet represents a specific
              relationship instance between two entities. Due to space constraints,
              presenting each step with its corresponding code snippet is beyond the
              scope of this paper. However, these details are available within the
              \texttt{prince2\char`_ontology.owl} file, which represents the PRINCE2
              ontology. Therefore, this paper will focus on the final results visualized
              within the Prot\'{e}g\'{e} environment.}
    \end{enumerate}

    Figure 16 illustrates a triplet set. The 925th line
    specifies relationship between classes. Based on this information in the
    control file, OWLschemafy generates the corresponding OWL/ XML encoded
    ontology. This ontology can then be visualized within the Prot\'{e}g\'{e} environment,
    as shown in the Figure 17.

    \showFig{./pictures/Fig_16.png} % filename to be displayed
            {1.0}                   % width
            {Triplet Definitions visualised in Prot\'{e}g\'{e}.} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-6pt}                  % space between figure and title
            {-2pt}                  % space after

    The Figure 17 shows the \texttt{documentCreatedBy} object property within
    the Prot\'{e}g\'{e} environment. It represents the relationship between the class
    individuals \texttt{ProjectInitiationDoc} and \texttt{ProjectExecutive}
    as follows:

    \begin{itemize}
        \piece{Subject and Object:}
             {\\These represent the instances (individuals) of the classes
              participating in the relationship.}
        \piece{Object Property:}
              {\\The label \texttt{documentCreatedBy} is displayed, indicating
              the name of the object property.}
        \piece{Domain Class:}
              {\\The domain class for this property is \texttt{Document} (a
              superclass of \texttt{ProjectInitiationDoc}). This signifies that instances of
              \texttt{Document} can participate in the relationship as subjects.}
        \piece{Range Class:}
              {\\The range class is \texttt{ProjectExecutive}, indicating that
              instances of \texttt{ProjectExecutive} can be objects associated
              with the \texttt{documentCreatedBy} property.}
        \piece{Data Property:}
              {\\The data property
              \texttt{documentAsActorsContribution}
              indicates the measure of the contribution as
              \texttt{xsd:String} encoded MEDIUM-value}
    \end{itemize}

    Figure 18 displays an annotation associated with the data property
    \texttt{documentAsActorsContribution}.
    \vspace{4pt}\\
    Data properties provide additional
    attributes to describe entities within the ontology: The label
    \texttt{documentAsActorsContribution} indicates the name of the data
    property.
    \vspace{4pt}\\
    The annotation text explains the purpose of the data property
    displayed. The text clarifies that \texttt{documentAsActorsContribution}
    identifies the portion of a document created by an actor
    (\texttt{ProjectExecutive}).

    \showFig{./pictures/Fig_17.png} % filename to be displayed
            {1.0}                   % width
            {Data Property Annotation visualised in Prot\'{e}g\'{e}.} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-6pt}                  % space between figure and title
            {24pt}                  % space after

    \showFig{./pictures/Fig_18.png} % filename to be displayed
            {1.0}                   % width
            {The annotation text clarifies
             the meaning of the predicate: \emph{The object property
             \texttt{documentCreatedBy} encodes which Document is created by
             whom}. It also informs about the inverse object property.} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-6pt}                  % space between figure and title
            {-2pt}                  % space after

    \showFig{./pictures/Fig_19.png} % filename to be displayed
            {1.0}                   % width
            {It displays the inverse of the original triplet
            (\texttt{ProjectExecutive} creates \texttt{ProjectInitiationDoc)}.\\
            It also shows the data property
            \texttt{actorsEffortAtDocumentCreation} is\\
            associated with the object class (\texttt{ProjectExecutive}).} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-6pt}                  % space between figure and title
            {-2pt}                  % space after

    \showFig{./pictures/Fig_20.png} % filename to be displayed
            {1.0}                   % width
            {Which indicates a shorthand notation used within Prot\'{e}g\'{e}
            to denote that the data properties
            (\texttt{documentAsActorsContribution} and
            \texttt{actorsEffortAtDocumentCreation}) are
            subclasses of the predefined
            \texttt{owl:topDataProperty} class in the
            OWL hierarchy. This placement helps
            categorize data properties within the ontology.} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-6pt}                  % space between figure and title
            {-2pt}                  % space after

    Overall, these five figures (Figures 17-21) show as Prot\'{e}g\'{e} screenshots
    visually represent the information encoded within the first triplet
    and its inverse from the provided triplet set of Figure 15, line 925.
    \vspace{4pt}\\
    They illustrate the relationships between classes
    (\texttt{documentCreatedBy}, \texttt{createsDocument}),
    the data properties associated with the relationships\\
    (\texttt{documentAsActorsContribution} and the\\
     \texttt{actorsEffortAtDocumentCreation}), as well as,
    how these properties connect to specific instances within
    the ontology.
%+
%   New Section 7
%-
\section
{Apache Jena vs OWLschemafy}
\vspace{10pt}\\ % ???
The field of ontology development offers a variety of tools and frameworks
to support the creation and management of knowledge structures. This chapter
compares OWLschemafy, the ontology development framework discussed throughout
this report, with Apache Jena, another prominent option within the Semantic
Web domain.
\vspace{4pt}\\
By highlighting the strengths and considerations associated with
each approach, this chapter aims to provide a more comprehensive understanding
of OWLschemafy's value proposition within the landscape of ontology development
tools. The comparison of Apache Jena and OWLschemafy custom framework for OWL
ontology development is as follows.

    \subsection
    {Programmer- Vs. Ontology-Orientation:}
    \vspace{-8pt}

    \begin{itemize}
        \piece{Apache Jena:}
              {Leans more towards programmer-oriented. It provides low-level
              APIs for building RDF models, manipulating statements, and
              interacting with OWL features. Users need to write Java code
              to define classes, properties, and axioms.}
        \piece{OWLschemafy:}
              {Seems more ontology-oriented. It uses a text-file based approach
              with control keywords, making it potentially easier for users
              familiar with ontology concepts but without extensive programming
              experience.}
    \end{itemize}

    \vspace{-10pt}
    \subsection
    {Bottom-Up Vs. Top-Down Approach:}
    \vspace{-8pt}
    \begin{itemize}
        \piece{Apache Jena:}
              {Offers a bottom-up approach. Users start by creating individual statements
              (triples) and build the ontology incrementally.}
        \piece{OWLschemafy:}
              {Promotes a more top-down approach. Users define class disjointness and
              object properties with annotations and relationships upfront, providing a
              higher-level view.}
    \end{itemize}

    \vspace{-10pt}
    \subsection
    {Additional Comparative Points:}
    \vspace{-8pt}
    \begin{itemize}
        \piece{Scalability:}
              {Jena is well-suited for large and complex ontologies due to its
              programmatic flexibility and integration with other RDF tools.
              OWLschemafy's scalability might be limited for very large ontologies
              as managing control files and parsing them could become cumbersome.}
        \piece{Interoperability:}
              {Jena offers seamless interoperability with other RDF and OWL tools
              due to its adherence to W3C standards. OWLschemafy's interoperability
              requires Prot\'{e}g\'{e}, as conversion tool for use with other OWL parsers
              or reasoners.}
        \piece{Reasoning Support:}
              {Apache Jena offers integration with various OWL reasoners, enabling
              automated reasoning and inference capabilities within ontologies.
              While OWLschemafy also supports reasoning, it currently relies on the
              Prot\'{e}g\'{e} ontology editor for this functionality.}
    \end{itemize}
    \vspace{-4pt}
%+
%   New Section 8
%-
\section
{Conclusion}
\vspace{-4pt}\\
    \subsection
    {The Power Of User-Centric Control:}
    This brief report has introduced OWLschemafy, a text-driven ontology
    generator that revolutionizes the approach to OWL development.
    By leveraging the accessibility and flexibility of text files,
    OWLschemafy empowers users to construct ontologies in a streamlined
    and user-friendly manner.

    \subsection
    {Key Features And Benefits:}
    \vspace{-10pt}
    \begin{itemize}
        \piece{Intuitive Text-Based Control:}
              {OWLschemafy departs from complex ontologylanguages,
              employing readily understandable text files. This
              intuitive interface lowers the barrier to entry for
              ontology development, making it accessible to a wider
              range of users.}
        \piece{Enhanced User Control and Flexibility:}
              {Users retain granular control over the ontology
              creation process through the detailed specifications
              within the text files. This flexibility empowers
              users to tailor the ontology structure and content
              to their specific needs.}
        \piece{Streamlined Workflow and Efficiency:}
              {OWLschemafy automates the generation of OWL ontologies
              based on the user-provided control files. This
              automation significantly reduces the time and effort
              required for ontology development compared to
              traditional methods.}
        \piece{Seamless Integration with Prot\'{e}g\'{e}:}
              {The tab-based indentation structure within the control
              files ensures compatibility with Prot\'{e}g\'{e}, a popular
              ontology editor. This allows users to seamlessly switch
              between text-based control and Prot\'{e}g\'{e}'s visual editing
              environment.}
    \end{itemize}
    \vspace{-6pt}

    \subsection
    {Potential For Diverse Use Cases:}
    OWLschemafy's unique approach transcends the limitations of
    traditional methods, opening doors for various use cases.
    Researchers can leverage it to create ontologies for diverse
    domains, streamlining knowledge representation and fostering
    collaboration.
    \vspace{4pt}\\
    Developers can utilize OWLschemafy to generate ontologies for
    semantic web applications, promoting interoperability and
    knowledge exchange. Educators can introduce ontology development
    concepts to students using the intuitive text-based interface,
    enhancing a deeper understanding of knowledge representation.
    \vspace{4pt}\\
    Finally, it is important to remember that the generated OWL
    file is compatible with most graph databases. However, a
    detailed discussion of the author's SPARQL queries executed
    using the ontotext GraphDB software tool falls outside the
    scope of this description.

    \subsection
    {Looking Ahead -- A Future Of Scalable And Enhanced Development:}
    The ongoing development of OWLschemafy explores promising
    avenues for future advancements. Envisioning the creation
    of highly expansive ontologies, the integration of relational
    databases as a control mechanism presents a compelling strategy
    for enhanced scalability. Furthermore, seamless integration with
    automated reasoning tools holds immense potential for ensuring
    the logical consistency and robustness of generated ontologies.
%+
%   New Section 9
%-
\section
{Software Background}
\vspace{10pt}\\
The software development environment consists of the following components:
\vspace{-2pt}
\begin{myindentpar}{20pt}
    \emph{Operating System:} macOS Monterey, (Version 12.5.1) running on an
    iMac (Retina 5k, 27-inch, Late 2015)     \\
    \emph{Java Runtime}: Java\raise0.4ex\hbox{\texttrademark{}}
    SE Runtime Environment (build 13.0.2+8)  \\
    \emph{Java Virtual Machine:} Java
    HotSpot\raise0.4ex\hbox{\texttrademark{}} 64-Bit Server
    VM (build 13.0.2+8, mixed mode, sharing)
    \vspace{4pt}\\
    \emph{Integrated Development Environment:} Eclipse IDE for Java
    Developers (includes Incubating components), Version: 2021-12 (4.22.0),
    Build id: 20211202-1639
    \vspace{2pt}\\
    \emph{Prot\'{e}g\'{e}:} Open-source ontology editor and framework
    for building intelligent systems, Version 5.6.3
\end{myindentpar}
\vspace{4pt}

Comprehensive documentation generated by JavaDoc (Figure 22) and all
source files are readily available.

    \showFig{./pictures/Fig_21.png} % filename to be displayed
            {1.0}                   % width
            {OWLschemafy development documentation generated by Java Doc.} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-6pt}                  % space between figure and title
            {2pt}                  % space after

Java applications are known for their platform independence.
As an illustration, Figure 23 below demonstrates the execution of OWLschemafy
within a terminal window on a macOS system.

    \showFig{./pictures/Fig_22.png} % filename to be displayed
            {1.0}                   % width
            {OWLschemafy Java application running on terminal window.} % title
            {\centering}            % indentation
            {2pt}                   % space before
            {-14pt}                 % space between figure and title
            {-4pt}                  % space after
\columnbreak
%+
%   New Section 10
%-
\section
{References}
\vspace{-10pt}\\
\renewcommand*\labelenumi{[\theenumi]}
\begin{enumerate}
    \densepiece{Allemang, D.,  Hendler, J. A. (2012). Semantic web for the working
                ontologist effective modeling in RDFS and Owl. Dean Allemang, Hendler. J.A.}
    \densepiece{Arp, R., Smith, B., Spear, A. D. (2015). Building ontologies with
                basic formal ontology. MIT Press}
    \densepiece{Curé, O., Blin, G. (2015). RDF database systems: Triples Storage
                and SPARQL query processing. Morgan Kaufmann}
    \densepiece{DuCharme, B. (2011). Learning Sparql: Querying and updating with SPARQL
                1.1. O’Reilly}
    \densepiece{Hofweber, T. (2018). Ontology and the ambitions of metaphysics. Oxford
                University Press}
    \densepiece{Horridge, M. (2011). A Practical Guide To Building OWL Ontologies
                Using Prot\'{e}g\'{e} 4 and CO-ODE Tools. The University Of Manchester
                Press}
    \densepiece{Ontology, conceptualization and epistemology for information systems,
                Software Engineering and Service science Miguel-Angel Sicilia,
                Christian Kop, Fabio Sartori. (2010). Springer}
    \densepiece{Owl. OWL - Semantic Web Standards. (n.d.)
                \hypersetup{hidelinks}\url{https://www.w3.org}}
    \densepiece{Segaran, T., Evans, C., Taylor, J. (2009). Programming in
                semantic web. O’Reilly}
    \densepiece{Yu, L. (2014). A developer’s guide to the semantic web.
                Springer Berlin Heidelberg}
\end{enumerate}

\vspace{8pt}
\small{Online Content}
\vspace{6pt}\\
\scriptsize{Any control and source data, extended data, supplementary
            information, and author details are available electronically.}
\vspace{4pt}\\
\begin{minipage}{\columnwidth}
\renewcommand{\arraystretch}{0.9}
\begin{tabular}{@{}@{\extracolsep{-10pt}}ll@{}}
\scriptsize{Base URL:}     & \scriptsize{\textcolor[RGB]{0,0,255}{\hypersetup{hidelinks}\url{http://www.edithlaszny.eu/ontology/OWLschemafy/}}}\\
\scriptsize{Present paper:}& \scriptsize{\texttt{paper/OWLschemafy\char`_V\char`_2\char`_002.pdf}}\\
\scriptsize{LaTeX source:} & \scriptsize{\texttt{paper/OWLschemafy\char`_V\char`_2\char`_002.tex}}\\
\scriptsize{Figures:}      & \scriptsize{\texttt{paper/figures/}}\\
\scriptsize{Control files:}& \scriptsize{\texttt{RunableEnv/*.txt}}\\
\scriptsize{Java sources:} & \scriptsize{\texttt{eclipseWorkSpacePRINCEP2/*}}\\
\scriptsize{Javadoc:}      & \scriptsize{\texttt{javadoc/index.html}}\\
\scriptsize{Author's data:}& \scriptsize{\texttt{authorsData/*.pdf}}\\
\scriptsize{OWL Ontology:} & \scriptsize{\texttt{RunableEnv/resultOntology/prince2\char`_ontology.owl}}\\
\end{tabular}
\end{minipage}

\vspace{122pt}

\textcolor[RGB]{255,0,0}{
    \begin{center}
        \line(1,0){\columnwidth}
    \end{center}
}
\vspace{-14pt}
\tiny{This work is licensed under a Creative Commons Attribution 4.0 International (CC BY 4.0) license.\\
     The author declares no conflicts of interest, including any competitive interests.\\
     This paper has been typeset from a \TeX/\LaTeX \hspace{2pt}file prepared by the author.}

\end{multicols}

\end{document}

%+
%  end of file  OWLschemafy_V_2_002.tex
%-
