Conference PaperPDF Available

Ontology-Driven Conceptual Modeling as a Service

Authors:

Abstract and Figures

In the past decades, the Unified Foundational Ontology (UFO) has played an important role in supporting the development of ontologies in academic and business settings, being employed to represent widely diverse domains. In this period, a dedicated community of researchers has worked to support UFO and its representation language, OntoUML, by creating the OntoUML Lightweight Editor (OLED). Now that a new version of OntoUML is available, the need for up-to-date tool support has exposed the limitations of OLED, its development context, and the difficulties of bringing research contributions to the hands of modelers. To tackle these issues, this paper reflects upon the experiences of this community taking into consideration the goals of researchers (as developers) and modelers to devise a new microservice-oriented modeling infrastructure for OntoUML, called OntoUML as a Service (OaaS). This infrastructure supports future practical contributions to the language with a focus on lowering the entry barrier for the development of new contributions and enabling an easier deployment to modelers. The paper also discusses the details of implementing OaaS through a number of projects that currently implement this infrastructure.
Content may be subject to copyright.
Ontology-Driven Conceptual Modeling as a Service
Claudenir M. Fonseca1,Tiago Prince Sales1,Victor Viola2,Lucas B. R. da Fonseca3,
Giancarlo Guizzardi1,4 and João Paulo A. Almeida5
1Conceptual and Cognitive Modelling Research Group (CORE), Free University of Bozen-Bolzano, Bolzano - Italy
2Farfetch, Porto - Portugal
3X-Team International, Melbourne - Australia
4Services, Cybersecurity & Safety, University of Twente, Enschede - The Netherlands
5Ontology & Conceptual Modeling Research Group (NEMO), Federal University of Espírito Santo - Brazil
Abstract
In the past decades, the Unied Foundational Ontology (UFO) has played an important role in supporting
the development of ontologies in academic and business settings, being employed to represent widely
diverse domains. In this period, a dedicated community of researchers has worked to support UFO and
its representation language, OntoUML, by creating the OntoUML Lightweight Editor (OLED). Now that
a new version of OntoUML is available, the need for up-to-date tool support has exposed the limitations
of OLED, its development context, and the diculties of bringing research contributions to the hands
of modelers. To tackle these issues, this paper reects upon the experiences of this community taking
into consideration the goals of researchers (as developers) and modelers to devise a new microservice-
oriented modeling infrastructure for OntoUML, called OntoUML as a Service (OaaS). This infrastructure
supports future practical contributions to the language with a focus on lowering the entry barrier for
the development new contributions and enabling an easier deployment to modelers. The paper also
discusses the details of implementing OaaS through a number of projects that currently implement this
infrastructure.
Keywords
ontology-driven conceptual modeling, Unied Foundational Ontology, OntoUML, service-architecture,
applied ontology
1. Introduction
For a few decades now, ontologies have supported organizations in building precise repre-
sentations of their problem domains. The inherent complexity of reality, however, places a
great burden on modelers when developing ontologies as they need to consistently account
for domains with very distinct characteristics. The usage of adequate formal languages in
the representation of ontologies plays a signicant role, in this sense, since these languages’
constructs (e.g., predicates, classes, or relations) may serve as better cognitive and formal tools
in the modeling task. OntoUML is an example of such a language, designed to enrich the Unied
Modeling Language (UML) [
1
] with the concepts of the Unied Foundational Ontology (UFO)
FOMI 2021: 11th International Workshop on Formal Ontologies meet Industry
"cmoraisfonseca@unibz.it (C. M. Fonseca); tiago.princesales@unibz.it (T. P. Sales); victorviola86@gmail.com
(V. Viola); lucas.bassetti@x-team.com (L. B. R. d. Fonseca); giancarlo.guizzardi@unibz.it (G. Guizzardi);
jpalmeida@ieee.org (J. P. A. Almeida)
©2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073
CEUR Workshop Proceedings (CEUR-WS.org)
1
Claudenir M. Fonseca et al. CEUR Workshop Proceedings 1–12
[
2
]. By leveraging the several logical, philosophical, and psychological theories collected in
UFO, OntoUML denes a set of constructs and
semantically-motivated syntactical constraints
[
3
]
tailored for ontology-driven conceptual modeling (ODCM). In other words, OntoUML shifts the
inherent complexity of reality towards the language’s denition such that every syntactically
valid model represents a sound ontology in terms of UFO.
One advantage of OntoUML being an extension of UML is that any UML CASE tool
1
that
includes the prole mechanism (representation of constructs as stereotyped elements, such as
classes and associations) could be used to build models. This advantage is limited, however,
since these tools are unable to support basic OntoUML features, such as checking language
constraints in users’ models to prevent the development of unsound ontologies. To provide
modelers with adequate support, a community of researchers and developers worked on the
development of the OntoUML Lightweight Editor (OLED) [
4
], a CASE tool based on the Eclipse
Modeling Framework (EMF) [
5
]. OLED, alongside a later spin-o tool, the Menthor Editor [
6
],
presented the most accurate implementation of OntoUML and oered state-of-the-art model
processing services, such as model verication, model simulation [
7
], anti-patterns detection
[
8
], and multiple transformation options (e.g., OWL, SWRL, SBVR) [
9
,
10
]. Additionally, OLED
would include model editing services beyond basic diagramming that also explored OntoUML’s
denitions, such as inductive modeling [
11
]. We broadly refer to these model editing and model
processing services as model intelligence services.
As the work towards a new version of OntoUML [
9
,
12
,
13
] – OntoUML 2 – began, the
demand for updated tools and model-based services exposed several limitations of both OLED
and Menthor, such as (i) its monolithic architecture that allowed for highly coupled components
and that signicantly hindered maintainability; (ii) its Ecore-based metamodel required changes
that would deeply aect all features making updates challenging; (iii) its inability to adequately
handle large-scale models; and (iv) the ever-growing technical-debt of the project, accumulated
over the years by losing several contributors (e.g., graduating students, researchers moving to
dierent institutions) who left pending issues on the services they developed. These limitations
are not specic to OntoUML or any single modeling language in that regard, but the long-term
consequences of the adopted software architecture and the research-centric environment in
which the tools were developed.
In this paper, we propose a microservice-based [
14
] infrastructure for OntoUML, referred
to as
OntoUML as a Service
(OaaS). This proposal is developed as an answer to a number of
requirements, presented in section 2, emerging from previous experiences of the OLED and
Menthor communities, and by the goals of involved stakeholders (i.e., developers, researchers,
and modelers). OaaS is discussed in section 3, where each artifact of the infrastructure as well
as their implementations are presented in detail. Currently available OaaS model intelligence
services are presented in section 4. By the end, we position OaaS in terms of OLED, Menthor,
and other related work in section 5, and present our nal remarks in section 6.
1Computer-aided software engineering tool.
2
Claudenir M. Fonseca et al. CEUR Workshop Proceedings 1–12
2. Stakeholders and Requirements
There are three main stakeholder types whose concerns constrain how we realized the new
OntoUML modeling infrastructure, namely:
Service Developer
: a person who implements model intelligence services. This is usually
a researcher with limited programming skills whose goal is to implement an algorithm
that manipulates OntoUML models (e.g. a transformation from OntoUML to gUFO [
15
]),
which she would like to make available to others via a modeling environment. Thus, a
service developer needs a programming library that oers the possibility to create, edit,
and query OntoUML models eciently, while having a low learning curve. Since the kind
of service to be implemented may varies signicantly, as well as the developers skill set,
the possibility to freely choose libraries, platforms, and even the programming languages
can be extremely desirable.
Modeler
: a person who designs OntoUML models, be it in an academic, governmental,
or industrial setting. Modelers want to develop high-quality models by leveraging model
intelligence services, but also to have an enjoyable experience while using the modeling
tool as a whole. Ideally, modelers prefer to stick with the tool they are accustomed to and
just have OntoUML support incorporated into it. For them, it is fundamental that their
tool is reliable and user-friendly. In industrial settings, it is also paramount that the tool
can handle large-scale models and support collaboration.
Tool Developer
: a developer who curates model intelligence services and aggregates
them in a tool to make them available to modelers. Tool developers are OntoUML
experts who are also experienced programmers. They depend on service developers to
create services, while service developers rely on them to make their services available to
modelers. Tool developers care about the overall experience modelers will have, so they
want to assure the quality of a service before incorporating it. Finally, tool developers seek
standardization of model intelligence services through a exible yet consistent interface,
that can be easily maintained, and that amounts to low additional technical debt.
With the drivers and characteristics of the aforementioned stakeholders in mind, we derived
the following core set of requirements for the new OntoUML modeling infrastructure:
R1
The technological requirements (e.g., frameworks, programming languages, platforms)
imposed upon service and tool developers by the infrastructure should be minimal;
R2 The learning curve for service developers to use the infrastructure should be low;
R3
Tool developers should be shielded from the implementation details of model intelligence
services, just as service developers should be shielded from the details of modeling tools;
R4 Infrastructure components should be highly decoupled;
R5 Infrastructure components should be easily maintainable;
R6 The infrastructure should be able to handle large-scale models;
R7
Model intelligence services should be easily integrable into (third party) modeling tools.
3
Claudenir M. Fonseca et al. CEUR Workshop Proceedings 1–12
3. OntoUML as a Service
To realize the aforementioned requirements, we developed a modeling infrastructure based on
a microservice architecture [
14
] and inspired by Model-Driven Engineering (MDE) [
16
] and
the Language Server Protocol (LSP)
2
. This infrastructure, deemed
OntoUML as a Service
(OaaS),
consists of:
ontouml-js: an OntoUML API to create, edit, and query models, written in Javascript.
ontouml-schema
: a specication of how to serialize OntoUML models as JSON objects.
ontouml-server
: a reference implementation of an OntoUML server, which exposes a
curated set of model intelligence services via a web API.
ontouml-vp-plugin
: a reference OntoUML modeling tool that consumes services from
the ontouml-server. It is implemented in Java as a plugin for Visual Paradigm.
This infrastructure is designed to support OntoUML modeling environments in a microservice
architecture, as depicted in Figure 1, which consists of modeling tools, OntoUML servers, and
model intelligence services.
Figure 1: The OaaS infrastructure: (1) a modeling tool requests a service provided by an OntoUML
server; (2) the OntoUML server executes the requested service passing the serialized model and addi-
tional arguments to the service; (3) the service process the received model employing a tailored On-
toUML API; (4) the service returns the result of its model processing to the server; (5) finally, the server
sends a response message to the modeling tool containing the service’s output.
In this picture, a
modeling tool
is an application with which modelers directly interact, such
as a desktop modeling tool (e.g. OLED, Menthor Editor, Visual Paradigm, MagicDraw, Astah) or
a browser-based tool. Such a tool provides model editing features and is responsible for meeting
modelers’ expectations regarding ease of use, consistency, and reliability, and for providing them
with an overall satisfying user experience. To provide model intelligence services, however,
tools must include a layer capable of performing HTTP requests to OntoUML servers.
An
OntoUML server
is an application that exposes model intelligence services via a web API.
It listens for requests from tools on dedicated endpoints, processes these requests, delegates
them to the corresponding services, and sends the results back to the tools. The communication
between a tool and a server is governed by OaaS’ service protocol, which species how to send
2https://microsoft.github.io/language-server-protocol/
4
Claudenir M. Fonseca et al. CEUR Workshop Proceedings 1–12
requests messages (e.g. which HTTP method to use, how to format the request body), as well as
how these requests should be answered (e.g. which HTTP status code to use, how to format the
response body). A crucial part of these messages is the OntoUML model being sent from the
tool to the server, which is structured according to the ontouml-schema (see subsection 3.1).
Lastly, a
model intelligence service
is an application that operates on an OntoUML model,
such as verifying its compliance with the language’s syntax or transforming it into an OWL
specication. It may be deployed as a library, in which case it can be directly executed from
within an OntoUML server, or it may be deployed in its own web server. In the latter case, the
OntoUML server will communicate with it using the same protocol that governs the tool-server
communication. Naturally, model intelligence services need to deserialize, parse, and manipulate
models they receive from requests. If the service is implemented in Javascript, this can be done
via ontouml-js, our OntoUML API (see subsection 3.2).
3.1. ontouml-schema
OaaS foresees the implementation of services that receive, as input, models serialized as JSON
objects. The shape of these objects is standardized by the
ontouml-schema3
, which is written
as a JSON document itself according to the JSON Schema
4
vocabulary. The purpose of this
specication is two-fold. First, it informs developers about OntoUML metamodel’s elements,
such as classes, relations, and generalization sets, as well as their properties. For instance, an
object describing a class has a boolean eld named
isAbstract
. It also denes how to serialize
diagrammatic information in a tooling independent way. Second, it can be used to automatically
validate if a serialized model conforms to its rules, accusing any deviations. Listing 1presents
an excerpt of an OntoUML model5serialized according to this schema.
Listing 1: Excerpt of an OntoUML model serialized into ontouml-schema.
{
"id": "sample_project",
"type": "Project",
"model": {
"id": "root_package",
"type": "Package",
"contents": [
{
"id": "person",
"type": "Class",
"stereotype": "kind",
"restrictedTo": ["functional-complex"]
}
]
},
"diagrams": [...]
}
The schema specication acts as a shared OntoUML "metamodel" for services and tools, but
there is no requirement for that to be their internal metamodels (in case they employ MDE).
3Source code at https://purl.org/krdb-core/ontouml-schema.
4https://json-schema.org/
5For the meaning of notions such as Kind, Subkind, Functional Complex, Material Relation, Relator, Category,
which appear in the gures and listings throughout this article, the reader is referred to [2].
5
Claudenir M. Fonseca et al. CEUR Workshop Proceedings 1–12
Internally, applications can simply maintain a compatibility layer that (de)serializes models as
necessary.
3.2. ontouml-js
The OaaS infrastructure, with its service contract relying on platform independent technologies
like JSON and HTTP, is designed to provide maximum exibility to service and tool developers
alike. However, this simplicity leaves a gap regarding programming APIs that can manipulate
OntoUML models. To ll it, OaaS relies on programming language-specic OntoUML APIs,
made available via package managers, such as NPM, for node.js, and Maven, for Java.
ontouml-js6
is one such API. It is a TypeScript library
7
that provides a collection of classes
corresponding to OntoUML metamodel’s elements, and an extensive set of easy to use methods
to create, modify, and query OntoUML models eciently. It also includes out-of-the-box
support for serializing and deserializing models compliant with the
ontouml-schema
, as well as
a validation function for such models. Moreover,
ontouml-js
provides classes and interfaces for
the implementation of model intelligence services, including service options and issues.
Listing 2: Using ontouml-js to create a model containing two classes and a relation.
let project = new Project({ name: ’My Project’ });
let model = project.createModel({ name: ’Model a.k.a. Root Package’ });
let person = model.createKind(’Person’);
let school = model.createKind(’School’);
let studiesAt = model.createMaterialRelation(person, school, ’studies at’);
The
ontouml-js
API is used by all currently available OaaS services (which are all coded in
Typescript), but a Java counterpart is already in the works, which is based on the (de)serialization
mechanism implemented for the ontouml-vp-plugin project.
3.3. ontouml-server
The
ontouml-server
project
8
provides a reference implementation of an OntoUML server in
the OaaS architecture, exposing a curated set of services. Each service route dened in the
server answers to HTTP POST requests from client tools which must be sent with a JSON
payload containing a serialized OntoUML model (in the
"project"
eld) and an object containing
all arguments necessary for the execution of the desired service (in the
"options"
eld), as
illustrated in Listing 3.
Listing 3: HTTP POST request sent to the ontouml-server requesting model transformation.
POST /transform/gufo
Content-Type: application/json
{
"project": {
"id" : "sample_project",
6Source code at https://purl.org/krdb-core/ontouml-js.
7TypeScript libraries can be used by both TypeScript and Javascript applications.
8Source code at https://purl.org/krdb-core/ontouml-server.
6
Claudenir M. Fonseca et al. CEUR Workshop Proceedings 1–12
"type" : "Project",
"model" : {...},
"diagrams": [...]
},
"options": {
"format":"Turtle",
"baseIri": "https://example.com"
}
}
A service request is answered with a JSON object containing the output generated by it (in
the
"result"
eld) and an optional array of issues that may have emerged during processing
(in the
"issues"
eld), such as errors that prevented the service from executing correctly or
warnings that are relevant to the requester. A successful response message uses the HTTP
status
200 OK
, while an error response message (sent for requests that could not be processed)
uses a status code according to the HTTP conventions. For instance,
400 Bad Request
would
be used to indicate that a request was sent with some error, such as lacking the
"project"
eld.
Listing 4presents an example of a successful response message to the prior request.
Listing 4: HTTP response (partial) received from the ontouml-server.
HTTP/1.1 200 OK
Content-Type: application/json
{
"result": "@prefix : <https://example.com#>.\n@prefix gufo: <http://purl.org/nemo/gufo#>.\n...",
"issues": null
}
The service contract dened by OaaS currently comprises the serialization of OntoUML
models, the shape of request messages, and the shape of responses. The service endpoint
corresponding to some service is dened by the specic server implementation, while the shape
of the elds
"options"
,
"result"
, and
"issues"
, are dened by the specic service implementation.
A standardization for the "issues" array eld is still under development.
All services currently available in
ontouml-server
, including model verication, model trans-
formations into (gUFO-based [
15
]) OWL ontologies and relational schemas [
10
], and modular-
ization [
17
], are executed inside the server itself. Nonetheless, OaaS allows for communication
between servers using the presented service contract. In this way, dedicated servers can act
as brokers, orchestrating and providing multiples services implemented in dierent program-
ming languages, frameworks, or libraries, with the HTTP protocol serving as the common
communication layer. Adopting this microservice architecture, OaaS can provide a higher-level
decoupling between the dierent artifacts.
3.4. ontouml-vp-plugin
The
ontouml-vp-plugin
project
9
is a plugin for Visual Paradigm
10
, a multi-platform CASE tool.
It adds a n extension to Visual Paradigm that enables the interaction with OntoUML servers.
In order to integrate it with OaaS, the plugin (i) adds OntoUML’s constructs (stereotypes for
9Available at https://purl.org/krdb-core/ontouml-plugin.
10https://www.visual-paradigm.com
7
Claudenir M. Fonseca et al. CEUR Workshop Proceedings 1–12
classes, associations, and attributes), (ii) enable model (de)serialization in compliance with
the
ontouml-schema
, and (iii) provide access to a deployed instance of the
ontouml-server
. In
addition to these features, the
ontouml-vp-plugin
also adds to the Visual Paradigm context
menus and event listeners that enhance the overall experience for OntoUML modelers, but the
decoupling enabled by OaaS allows tool developers to rely on existing modeling tools to provide
most of the model editing features necessary for modelers. Moreover, service developers must
not concern themselves with the tool being used by modelers when developing a service to
provide model processing features as they work on completely decoupled projects. Figure 2
presents an example OntoUML model being built on Visual Paradigm and part of the interface
provided by the ontouml-vp-plugin.
Figure 2: An OntoUML model being built in Visual Paradigm using the ontouml-vp-plugin.
Notice that OaaS can support the development of tools tailored for OntoUML, like OLED and
the Menthor Editor, as well as extensions of commercial modeling tools, which may even share
an OntoUML server. The latter is particularly interesting in industrial settings, as organizations
tend to stick with the modeling tools they have already been chosen.
4. Model Intelligence Services
We propose the notion of
model intelligence services
as those services designed to support
model engineering tasks (e.g., design, verication, validation, verbalization) by leveraging the
language’s metamodel. These services are intended to be entirely, or mostly, automated. Both
model processing and model editing services can t the notion of model intelligence services.
Their implementation in microservice architectures, however, is not required, being this a
8
Claudenir M. Fonseca et al. CEUR Workshop Proceedings 1–12
particular aspect of OaaS’s implementation.
In OntoUML’s case, its model intelligence services can leverage UFO’s knowledge, which is
embedded into the language’s denition, to support more sophisticated features. At the moment,
the set of services developed in the OaaS infrastructure is the following:
verification
: the verication service [
9
] checks if a model is compliant with OntoUML’s
syntax, returning a list of deviations. Each deviation has a severity level. An
"error"
indicates violations that generate logical or ontological inconsistencies in the model,
while a "warning" indicates a lesser problem, such as an under-specied model.
ontouml2gufo
: this OWL transformation service generates ontologies based on the
Lightweight Implementation of the Unied Foundational Ontology (gUFO) [
15
], allowing
OntoUML users to take advantage of their ontologies in the OWL ecosystem.
ontouml2db
: the relational database transformation service generates relational schemas
from OntoUML models [
10
]. More specically, OntoUML’s semantics informs the service’s
algorithm on suitable strategies to generate table declarations turning the knowledge
present in the ontology into design decisions.
ontouml2alloy
: the Alloy transformation service is an update of the simulation service
originally present in OLED [
7
]. The transformation generates the necessary les for
model simulation through the Alloy Analyzer tool [18], now supporting OntoUML 2.
complexity management
: the complexity management service oers algorithms to
handle large-scale models, such as pattern-based view extraction [
19
], modularization
based on relational contexts [
17
], and model abstraction [
20
]. These algorithms help
modelers to organize and communicate large models in a cognitively tractable manner.
5. Related Work
The requirements driving the proposal and implementation of OaaS (see section 4) are largely
inspired by limitations observed in past implementations of software to support OntoUML
modeling, particularly with the observations OLED [
4
] and Menthor [
6
]. Thus, a comparison
between OaaS and these tools, in light of these requirements, can highlight the benets of our
approach.
In the case of OLED and Menthor, a developer seeking to implement a new service will face a
large monolithic Java project. This architecture, which is similar to many other tools, imposes
strict technological requirements on this developer, such as using Java and the ECore-based
OntoUML API [
21
], which goes against
R1
. As consequence, they face a steep learning curve on
both project-specic and platform-specic aspects (e.g., learning the EMF which supports these
tools), which hurts
R2
. Not only that, but developers cannot adopt technologies they are more
familiar with or that better suit their needs due to incompatibilities with the rest of the project.
OaaS overcomes such issues for model processing services by hiding them behind HTTP APIs.
The use of an ECore-based API for manipulating models has shown, in practice, to be a
serious shortcoming when querying large-scale models, thus hindering
R6
. This is particularly
evinced when implementing model-driven transformations on such models and running queries
like "list of all descendants of class X", which required parsing the whole model to answer. We
9
Claudenir M. Fonseca et al. CEUR Workshop Proceedings 1–12
have resolved this issue on
ontouml-js
, our custom-made API, by adopting a combination of
derived elds and dynamic caching, which resulted in a drastic increase in performance.
The services available on OLED and Menthor, for being developed inside monolithic archi-
tectures, cannot be easily reused by other applications, even if these share the same necessary
dependencies. Even with the adoption of proper modularization of its code, many interaction
points between services still remain, and the involvement of multiple developers in the history
of the tool contributes to its lower coordination. In fact, that was a signicant challenge in the
development of Menthor, which had OLED’s code as its starting point. The reuse of OLED’s
code led to laborious code refactoring to avoid re-implementing shared features. Designed with
R7
in mind, OaaS requires a separation between its artifacts, promoting the reuse of servers
between tools, the reuse of services by dierent servers, as well as the reuse of tailored libraries
implemented and shared by developer communities.
The interdependence of services within OLED and Menthor also hinders their maintainability,
as it becomes harder to remove, replace, or update services (thus, hurting
R5
). This is also
relevant as the original services’ developers, oftentimes PhD candidates and researchers, no
longer maintain their projects, which often forces tool developers to drop services due to a
lack of capable developers to support it (see
R4
). OaaS oers a more reliable basis to prevent
such issues, being easier to drop individual services in these ultimate scenarios. Moreover,
the possibility of deploying services as containers can guarantee a consistent environment for
running services in the long-term, regardless of changes in operational systems, programming
languages, or order aspects that could make services’ code deprecated otherwise, as was recently
the case of Adobe Flash in web browsers.
Finally, OaaS’s tools and services are completely hidden from one another behind the service
contract, which means the implementation one is transparent to the other (see
R3
). OLED
and Menthor may not require from developers similar degrees of transparency, which can
enable certain features beyond the capabilities of OaaS’s current scope, but the cost of higher
complexity and dependency of developers adherence to internally dened interfaces and APIs.
Another approach related to OaaS is the Language Server Protocol (LSP). Not unlike OaaS,
LSP denes a service contract between text editors and language servers, where text editors
can request any kind of feature (including text editing and processing features) from a server
dedicated to a target textual language. This not only frees the text editor to focus on the front-
end that users interact with, but also promotes great reuse of language servers that can be easily
added to editors and shared between editors. In this regard, LSP is much more comprehensive
than OaaS comprising all sorts of use cases involving textual languages, but on the other hand, it
requires editors that support the protocol in other to work. OaaS is tailored to a single language
and facilitates the extension of existing tools rather them requiring the development of new
ones. Moreover, visual languages like OntoUML have a model/view separation not present in
textual languages that can be easily serialized and may rely on the position of tokens in text les
to express semantics. Eorts to promote an extension of LSP to include visual languages exist,
but are still gaining traction and face some of the same drawbacks like requiring compatible
tools. Nonetheless, further investigation of LSP should inspire future developments of OaaS as
it grows in scope.
10
Claudenir M. Fonseca et al. CEUR Workshop Proceedings 1–12
6. Conclusions
This work presents the OaaS infrastructure, which is designed to support the implementa-
tion of future practical research in OntoUML. This infrastructure, based on a microservice
architecture and materialized in a number connected projects (i.e.,
ontouml-schema
,
ontouml-
server
,
ontouml-vp-plugin
, and
ontouml-js
), seeks to mitigate a number of issues observed in
the development of the OLED and Menthor Editor tools.
As result, the proposal enforces the decoupling of its components by design (
R4
and
R3
),
exposing developers to a very low learning curve to integrate their services into OaaS (
R2
), as
well as imposing almost no technological requirements on them (
R1
). We expect these aspects,
along with the improved maintainability (
R5
) and performance (
R6
), to foster applied research
in OntoUML. Moreover, we also expect these services to arrive sooner to modelers as they can
be easily integrated into (third-party) tools these modelers are used to work with (R7).
As future work, we should broaden OaaS’ scope to cover use cases where the current service
contract oers limited support, particularly those involving model editing features and stateful
communication. LSP should also be analyzed in more detail as to identify use cases also applicable
to OaaS and investigate the possibility of employing OntoUML servers in tools supporting LSP.
We also hope to mature the infrastructure by supporting additional development resources,
such as new OntoUML libraries (particularly a library for Java based on the
ontouml-vp-plugin
project) and project templates for services.
Acknowledgments
We are grateful to the Zorginstituut Nederland supporting this initiative in the context of the
ODIN and THOR projects. We thank them for testing and giving feedback on the rst iterations
of this modeling infrastructure. Claudenir M. Fonseca and Giancarlo Guizzardi are supported
by the NeXON Project (Free University of Bozen-Bolzano). This study was nanced in part by
CAPES (grant 23038.028816/2016-41) and CNPq (grants 313687/2020-0 and 407235/2017-5).
References
[1]
OMG
®
Unied Modeling Language
®
, OMG
®
Unied Modeling Language
®
(OMG UML
®
)
Version 2.5.1, Technical Report, Object Management Group (OMG
®
), 2017. URL: http:
//www.omg.org/spec/UML/2.5.1.
[2]
G. Guizzardi, Ontological foundations for structural conceptual models, Ph.D. thesis,
University of Twente, 2005.
[3]
V. A. Carvalho, J. P. A. Almeida, G. Guizzardi, Using reference domain ontologies to dene
the real-world semantics of domain-specic languages, in: M. Jarke, et al. (Eds.), Advanced
Information Systems Engineering, Springer, Cham, 2014, pp. 488–502.
[4]
J. Guerson, T. P. Sales, G. Guizzardi, J. P. A. Almeida, OntoUML Lightweight Editor: A
model-based environment to build, evaluate and implement reference ontologies, in: IEEE
19th International Enterprise Distributed Object Computing Workshop, 2015, pp. 144–147.
11
Claudenir M. Fonseca et al. CEUR Workshop Proceedings 1–12
[5]
D. Steinberg, F. Budinsky, E. Merks, M. Paternostro, EMF: Eclipse Modeling Framework,
Addison-Wesley, 2008.
[6]
J. L. R. Moreira, T. P. Sales, J. Guerson, B. F. B. Braga, F. Brasileiro, V. Sobral, Menthor
Editor: An ontology-driven conceptual modeling platform, in: O. Kutz, S. de Cesare (Eds.),
2nd Joint Ontology Workshops (JOWO), volume 1660, CEUR, 2016.
[7]
A. B. Benevides, G. Guizzardi, B. F. B. Braga, J. P. A. Almeida, Validating modal aspects
of OntoUML conceptual models using automatically generated visual world structures, J.
Univers. Comput. Sci. 16 (2010) 2904–2933.
[8]
T. P. Sales, G. Guizzardi, Ontological anti-patterns: Empirically uncovered error-prone
structures in ontology-driven conceptual models, Data Know. Eng. 99 (2015) 72–104.
[9]
G. Guizzardi, C. M. Fonseca, J. P. A. Almeida, T. P. Sales, A. B. Benevides, D. Porello,
Types and taxonomic structures in conceptual modeling: A novel ontological theory and
engineering support, Data Know. Eng. 134 (2021) 101891.
[10]
G. L. Guidoni, J. P. A. Almeida, G. Guizzardi, Transformation of ontology-based conceptual
models into relational schemas, in: G. Dobbie, et al. (Eds.), Conceptual Modeling. ER 2020,
Springer, Cham, 2020, pp. 315–330.
[11]
G. Guizzardi, A. P. das Graças, R. S. S. Guizzardi, Design patterns and inductive modeling
rules to support the construction of ontologically well-founded conceptual models in
OntoUML, in: Advanced Information Systems Engineering Workshops, 2011, pp. 402–413.
[12]
C. M. Fonseca, D. Porello, G. Guizzardi, J. P. A. Almeida, N. Guarino, Relations in ontology-
driven conceptual modeling, in: International Conference on Conceptual Modeling,
Springer, 2019, pp. 28–42.
[13]
J. P. A. Almeida, R. A. Falbo, G. Guizzardi, Events as entities in ontology-driven conceptual
modeling, in: International Conference on Conceptual Modeling, Springer, 2019, pp.
469–483.
[14]
J. Lewis, M. Fowler, Microservices: a denition of this new architectural term, https:
//martinfowler.com/articles/microservices.html, 2014.
[15]
J. P. A. Almeida, G. Guizzardi, R. A. Falbo, T. P. Sales, gUFO: A lightweight implementation
of the Unied Foundational Ontology (UFO), http://purl.org/nemo/gufo, 2019.
[16]
D. Schmidt, Guest editor’s introduction: Model-driven engineering, Computer 39 (2006)
25–31.
[17]
G. Guizzardi, T. P. Sales, J. P. A. Almeida, G. Poels, Relational contexts and conceptual
model clustering, in: J. Grabis, D. Bork (Eds.), The Practice of Enterprise Modeling. PoEM
2020, volume 400, Springer, Cham, 2020, pp. 211–227.
[18] D. Jackson, Software Abstractions: logic, language, and analysis, MIT press, 2012.
[19]
G. Figueiredo, A. Duchardt, M. M. Hedblom, G. Guizzardi, Breaking into pieces: An
ontological approach to conceptual model complexity management, in: 12th International
Conference on Research Challenges in Information Science (RCIS), IEEE, 2018, pp. 1–10.
[20]
G. Guizzardi, G. Figueiredo, M. M. Hedblom, G. Poels, Ontology-based model abstraction,
in: 13th International Conference on Research Challenges in Information Science (RCIS),
IEEE, 2019, pp. 1–13.
[21]
R. Carraretto, A Modeling Infrastructure for OntoUML, Technical Report, Ontology &
Conceptual Modeling Research Group, Federal University of Espírito Santo, Brazil, 2010.
12
... -Modeling tools, e.g., the OntoUML Plugin for Visual Paradigm [18] and the OpenPonk Modeling platform [53]; ...
... Designed to support the development of model intelligence services in OntoUML [18], the ontouml-schema project specifies how to serialize OntoUML in JSON. In this format, OntoUML models can be easily exchanged between clients and servers communicating over HTTP. ...
... This relationship shows that ontological analysis is often developed in academia, where models are generally created to explain domains and develop conceptualizations. There are also more practical models developed to solve specific problems, such as supporting interoperability (22) and software engineering (18). We believe that these types of models would be more common among models developed in industry, but our analysis could not prove this hypothesis because of the limited number of models developed in 30 this context in the analyzed sample. ...
... The collaborators obtained images of OntoUML/UFO-based models from papers and technical reports and manually rebuilt them on the latest version (v16.3) of the Visual Paradigm (VP) modeling editor 2 using the ontouml-vp-plugin 3 . This plugin is an extension to VP that offers several important modeling services [6]. For example, it allows the use of OntoUML constructs (stereotypes for classes, associations, and attributes) when building UML class diagrams, and supports syntax verification, model serialization in JSON and Web Ontology Language (OWL), as well as model modularization and abstraction. ...
... We structured the dataset folders as from data. This is a vocabulary designed to support the serialization and exchange of OntoUML models in compliance with the ontouml-schema 13 , which is a specification of how to serialize OntoUML models as JSON objects [6]. This file provides a specific URI for all data from the model 14 , and its publication allows anyone to access and manipulate all the model's instances; Note that the vpp, yaml, and bib files are the ones provided by the collaborators. ...
Chapter
Full-text available
Conceptual models are artifacts representing conceptualizations of particular domains. Hence, multi-domain model catalogs serve as empirical sources of knowledge and insights about specific domains, about the use of a modeling language’s constructs, as well as about the patterns and anti-patterns recurrent in the models of that language crosscutting different domains. However, to support domain and language learning, model reuse, knowledge discovery for humans, and reliable automated processing and analysis by machines, these catalogs must be built following generally accepted quality requirements for scientific data management. Especially, all scientific (meta)data—including models—should be created using the FAIR principles (Findability, Accessibility, Interoperability, and Reusability). In this paper, we report on the construction of a FAIR model catalog for Ontology-Driven Conceptual Modeling research, a trending paradigm lying at the intersection of conceptual modeling and ontology engineering in which the Unified Foundational Ontology (UFO) and OntoUML emerged among the most adopted technologies. In this initial release, the catalog includes over a hundred models, developed in a variety of contexts and domains. The paper also discusses the research implications for (ontology-driven) conceptual modeling of such a resource.KeywordsOntologyOntoumlData catalogFairLinked data
... The collaborators obtained images of OntoUML/UFO-based models from papers and technical reports and manually rebuilt them on the latest version (v16.3) of the Visual Paradigm (VP) modeling editor 4 using the ontouml-vp-plugin 5 . This plugin is an extension to VP that offers several important modeling services [6]. For example, it allows the use of OntoUML constructs (stereotypes for classes, associations, and attributes) when building UML class diagrams, and supports syntax verification, model serialization in JSON and Web Ontology Language (OWL), as well as model modularization and abstraction. ...
... We structured the dataset folders as from data. This is a vocabulary designed to support the serialization and exchange of OntoUML models in compliance with the ontouml-schema 15 , which is a specification of how to serialize OntoUML models as JSON objects [6]. This file provides a specific URI for all data from the model 16 , and its publication allows anyone to access and manipulate all the model's instances; Note that the vpp, yaml, and bib files are the ones provided by the collaborators. ...
Conference Paper
Full-text available
Conceptual models are artifacts representing conceptualizations of particular domains. Hence, multi-domain model catalogs serve as empirical sources of knowledge and insights about specific domains, about the use of a modeling language’s constructs, as well as about the patterns and anti-patterns recurrent in the models of that language crosscutting different domains. However, to support domain and language learning, model reuse, knowledge discovery for humans, and reliable automated processing and analysis by machines, these catalogs must be built following generally accepted quality requirements for scientific data management. Especially, all scientific (meta)data—including models—should be created using the FAIR principles (Findability, Accessibility, Interoperability, and Reusability). In this paper, we report on the construction of a FAIR model catalog for Ontology-Driven Conceptual Modeling research, a trending paradigm lying at the intersection of conceptual modeling and ontology engineering in which the Unified Foundational Ontology (UFO) and OntoUML emerged among the most adopted technologies. In this initial release, the catalog includes over a hundred models, developed in a variety of contexts and domains. The paper also discusses the research implications for (ontology-driven) conceptual modeling of such a resource.
... The foundational distinctions introduced by UFO can be incorporated into domain ontologies using a well-founded UML profile dubbed OntoUML [18,25]. Dedicated tool support (https://github.com/OntoUML/ontouml-vp-plugin) is available to ensure the ontologies produced with OntoUML follow the foundational rules established in UFO [25,26]. OWL 2 DL implementations can be obtained automatically and leverage the UFO implementation in OWL dubbed gUFO [27] ("gentle" UFO). ...
Chapter
Full-text available
There are a number of standards aiming to facilitate the exchange of competence data in the educational and job market areas. Despite their relevance, we have observed that they could benefit from an in-depth analysis of the notion of competence, given its central role in the intended application areas. This includes addressing facets of competence not only when attributed to particular individuals, but also when required by occupations in general. A comprehensive account for competences should ideally account for competence-related elements such as knowledge, attitudes, skills. It should also countenance their performance—related to tasks, their context, and outcomes—as well as their evolution over time (in order to account for the notion of ‘proficiency’). While some of these aspects are addressed in the existing standards, they are addressed in a partial manner, and a comprehensive conceptualization that can serve as a reference for articulating the various perspectives is still lacking. This is the focus of Core-O as a well-founded competence reference ontology.
... The foundational distinctions introduced by UFO can be incorporated into domain ontologies using a well-founded UML profile dubbed OntoUML [18,25]. Dedicated tool support (https://github.com/OntoUML/ontouml-vp-plugin) is available to ensure the ontologies produced with OntoUML follow the foundational rules established in UFO [25,26]. OWL 2 DL implementations can be obtained automatically and leverage the UFO implementation in OWL dubbed gUFO [27] ("gentle" UFO). ...
Conference Paper
Full-text available
There are a number of standards aiming to facilitate the exchange of competence data in the educational and job market areas. Despite their relevance, we have observed that they could benefit from an in-depth analysis of the notion of competence, given its central role in the intended application areas. This includes addressing facets of competence not only when attributed to particular individuals, but also when required by occupations in general. A comprehensive account for competences should ideally account for competence-related elements such as knowledge, attitudes, skills. It should also countenance their performance---related to tasks, their context, and outcomes---as well as their evolution over time (i.e., proficiency). While some of these aspects are addressed in the existing standards, they are addressed in a partial manner, and a comprehensive conceptualization that can serve as a reference for articulating the various perspectives is still lacking. This is the focus of Core-O as a well-founded competence reference ontology.
... Ontology plays an important role in representing applications in various domains. The ontology can be used to capture core data of design and to support smart digital design, modelling, simulation and other analysis applications [108]. It can be used to solve the mismatch issues between different services. ...
Chapter
Modelling and Simulation (M&S) are critical capabilities for Cloud Computing. M&S products and services are valuable resources that have to be easily accessible and available on demand in a cost-effective way to users; they provide the required level of agility so that capabilities can be integrated quickly and easily. To address new design and manufacturing challenges in Industry 4.0, digital-driven technologies use simulation tools, Computer Aided Design (CAD), Product Lifecycle Management (PLM) systems and Extended Reality (XR) services to support digital design and information flow throughout a product lifecycle. Thus, XR creates new business value by improving the customer journey, optimizing employee performance, and developing new content and services. The vision of Modelling and Simulation as a Service (MSaaS) aims to make products, data, and processes easily accessible and available on-demand to all users to improve operational effectiveness. The scope of this essay is to provide a comprehensive vision of MSaaS for products, data, and processes in combination with XR services to improve operational effectiveness under the framework of Industry 4.0.
... OntoUML defines a set of constructs and semantically-motivated syntactical constraints tailored for ODCMs [3]. In other words, OntoUML shifts the inherent complexity of reality towards the language's definition in such a way that every syntactically valid model represents a sound ontology in terms of UFO [6]. With this in mind, patterns for ODCM's abstractions were initially developed in terms of OntoUML [12,18]. ...
Conference Paper
Full-text available
Ontology-driven conceptual models are precise and semantically transparent domain descriptions that enable the development of information systems. As symbolic artefacts, such models are usually considered to be self-explanatory. However, the complexity of a system significantly correlates with the complexity of the conceptual model that describes it. Abstractions of both conceptual models and ontology-driven conceptual models are thus considered to be a promising way to improve the understandability and comprehensibility of those models. Although algorithms for providing abstractions of such models already exist, they still lack precisely formulated formal semantics. This paper aims to provide an approach towards the formalization of the abstraction process. We specify in first-order modal logic one of the graph-rewriting rules for ontology-driven conceptual model abstractions, in order to verify the correctness of the corresponding abstraction step. We also assess the entire network of abstractions of ontology-driven conceptual models and discuss existing drawbacks.
... To develop the models that represent the DPO and its modules, we use the OntoUML plugin for Visual Paradigm [34], a reference tool for OntoUML modelling. The plugin not only supports the creation of OntoUML models; it can automatically verify if they comply with the syntactic constraints of the language. ...
... although there are a few alternative foundational ontologies (see [17]), UFO is the only one among these that is accompanied by a full-blown modeling language (On-toUML) with its tool ecosystem. The former enables the representation of our models in a conceptual modeling diagrammatic language, thus, facilitating their accessibility by requirements engineers, and the latter allows one to potentially leverage this tool ecosystem for model verification, validation, verbalization and code generation [30,28]. In particular, it allows for the generation of logical specifications in OWL/SWRL for the models proposed here, thus, enabling automated reasoning over these models; ...
Article
Full-text available
In a world where Artificial Intelligence (AI) is pervasive, humans may feel threatened or at risk by giving up control to machines. In this context, ethicality becomes a major concern to prevent AI systems from being biased, making mistakes, or going rogue. Requirements Engineering (RE) is the research area that can exert a great impact in the development of ethical systems by design. However, proposing concepts, tools and techniques that support the incorporation of ethicality into the software development processes as explicit requirements remains a great challenge in the RE field. In this paper, we rely on Ontology-based Requirements Engineering (ObRE) as a method to elicit and analyze ethicality requirements 3. ObRE applies ontological analysis to ontologically unpack terms and notions that are referred to in requirements elicitation. Moreover, this method instantiates the adopted ontology and uses it to guide the requirements analysis activity. In a previous paper, we presented a solution concerning two ethical principles , namely Beneficence and Non-maleficence. The present paper extends the previous work by targeting two other important ethicality principles, those of Explicability and Autonomy. For each of these new principles, we do ontological unpacking of the relevant concepts, and we present requirements elicitation and analysis guidelines, as well as examples in the context of a driverless car case. Furthermore, we validate our approach by analysing the requirements elicitation made for the driverless car case in contrast with a similar case, and by assessing our method's coverage w.r.t European Union guidelines for Trustworthy AI.
... OWL, in contrast, being a monotonic language and having no built in notion of temporal modality is particularly limited in modeling dynamic aspects of the domain. Finally, OntoUML modelers can count on a rich ecosystem of tools for model construction, verification, OWL generation, validation and verbalization [5,11]. ...
Chapter
Full-text available
In this paper, we explore conceptual modeling as a means to improve the explicit representation of key aspects of a legal procedure. We employ in tandem an ontology-based structural conceptual model and a behavioral process model as complementary views on a legal subject matter. We examine as a case a specific type of appeal in the Brazilian legal system and establish a correspondence between elements in the models and fragments of the specific norms on which they are grounded. These correspondences are expressed with identifiers using the Brazilian LexML identification scheme.
Article
Full-text available
Types are fundamental for conceptual modeling and knowledge representation, being an essential construct in all major modeling languages in these fields. Despite that, from an ontological and cognitive point of view, there has been a lack of theoretical support for precisely defining a consensual view on types. As a consequence, there has been a lack of precise methodological support for users when choosing the best way to model general terms representing types that appear in a domain, and for building sound taxonomic structures involving them. For over a decade now, a community of researchers has contributed to the development of the Unified Foundational Ontology (UFO) - aimed at providing foundations for all major conceptual modeling constructs. At the core of this enterprise, there has been a theory of types specially designed to address these issues. This theory is ontologically well-founded, psychologically informed, and formally characterized. These results have led to the development of a Conceptual Modeling language dubbed OntoUML, reflecting the ontological micro-theories comprising UFO. Over the years, UFO and OntoUML have been successfully employed on conceptual model design in a variety of domains including academic, industrial, and governmental settings. These experiences exposed improvement opportunities for both the OntoUML language and its underlying theory, UFO. In this paper, we revise the theory of types in UFO in response to empirical evidence. The new version of this theory shows that many of OntoUML’s meta-types (e.g. kind, role, phase, mixin) should be considered not as restricted to substantial types but instead should be applied to model endurant types in general, including relator types, quality types, and mode types. We also contribute with a formal characterization of this fragment of the theory, which is then used to advance a new metamodel for OntoUML (termed OntoUML 2). To demonstrate that the benefits of this approach are extended beyond OntoUML, the proposed formal theory is then employed to support the definition of UFO-based lightweight Semantic Web ontologies with ontological constraint checking in OWL. Additionally, we report on empirical evidence from the literature, mainly from cognitive psychology but also from linguistics, supporting some of the key claims made by this theory. Finally, we propose a computational support for this updated metamodel.
Chapter
Full-text available
Despite the existence of several strategies for transforming structural conceptual models into relational schemas, there are a number of features of ontology-based conceptual models that have not been taken into account in the existing literature. Most approaches fail to support conceptual models that: (i) include overlapping or incomplete generalizations; (ii) support dynamic classification; (iii) have multiple inheritance; and (iv) have orthogonal hierarchies. This is because many of the approaches discussed in the literature are based on the object-relational mapping and, as a consequence, assume primitives underlying object-oriented programming languages (instead of conceptual modeling languages). This paper addresses this gap, focusing on the realization of taxonomic hierarchies of ontology-based conceptual models. We explore some ontological meta-properties that characterize classes in these models (sortality and rigidity) to guide the transformation and avoid some problems in existing approaches.
Chapter
Full-text available
In recent years, there has been a growing interest in the use of reference conceptual models to capture information about complex and sensitive business domains (e.g., finance, healthcare, space). These models play a fundamental role in different types of critical semantic interoperability tasks. Therefore, it is essential that domain experts are able to understand and reason with their content. In other words, it is important for these reference conceptual models to be cognitively tractable. This paper contributes to this goal by proposing a model clustering technique that leverages the rich semantics of ontology-driven conceptual models (ODCM). In particular, the technique employs the notion of Relational Context to guide automated model breakdown. Such Relational Contexts capture all the information needed for understanding entities “qua players of roles” in the scope of an objectified (reified) relationship (relator).
Conference Paper
Full-text available
For over a decade now, a community of researchers has contributed to the ontological foundations of Conceptual Modeling by participating to the development of the Unified Foundational Ontology (UFO) and the UFO-based modeling language OntoUML, which have been successfully employed in a number of different sectors. The empirical feedback from these experiences led us to reconsider UFO's theory of relations, proposing a new theory that has already been applied to model subtle notions in the business domain, such as value, risk, service, and contract. In this paper, we advance a first formal characterization of this new theory, which is then used to design a new metamodel for OntoUML.
Conference Paper
Full-text available
The Unified Foundational Ontology (UFO) has been used to provide foundations for the major conceptual modeling constructs. This ontology has led to the OntoUML Ontology-Driven Conceptual Modeling language, a UML class diagram profile reflecting the ontological micro-theories comprising UFO. So far, the focus of OntoUML has been on the representation of structural aspects of a domain (endurant types and their relations), corresponding to a fragment of UFO dubbed UFO-A. This paper extends OntoUML by addressing the representation of event types, reflecting the UFO-B foundational ontology of events. Based on the ontological distinctions and axiomatization provided by UFO-B, we define new OntoUML constructs and guidelines for the conceptual modeling of events and event relations in structural conceptual models.
Conference Paper
Full-text available
In recent years, there has been a growth in the use of reference conceptual models to capture information about complex and critical domains. However, as the complexity of domain increases, so does the size and complexity of the models that represent them. Over the years, different techniques for complexity management in large conceptual models have been developed. In particular, several authors have proposed different techniques for model abstraction. In this paper, we leverage on the ontologically well-founded semantics of the modeling language OntoUML to propose a novel approach for model abstraction in conceptual models. We provide a precise definition for a set of Graph-Rewriting rules that can automatically produce much-reduced versions of OntoUML models that concentrate the models' information content around the ontologically essential types in that domain, i.e., the so-called Kinds. The approach has been implemented using a model-based editor and tested over a repository of OntoUML models.
Conference Paper
Full-text available
In recent years, there has been a growth in the use of reference conceptual models, in general, and domain ontologies, in particular, to capture information about complex and critical domains. These models play a fundamental role in different types of critical semantic interoperability tasks. Therefore, it is essential that domain experts are able to understand and reason using the models' content. In other words, it is important that conceptual models are cognitively tractable. However, it is unavoidable that when the information of the represented domain grows, so does the size and complexity of the artifacts and models that represent them. For this reason, more sophisticated techniques for complexity management in ontology-driven conceptual models, need to be developed. Some approaches are based on the notion of model modularization. In this paper, we follow the work on model modularization to present an approach for view extraction for the ontology-driven conceptual modeling language OntoUML. We provide a formal definition for ontological views over OntoUML conceptual models that completely leverages on the ontologically well-grounded real-world semantics of that language. Moreover, we present a plug-in tool, particularly developed for an OntoUML model-based editor that implements this formal view structure in terms of queries defined over the OntoUML metamodel embedded in that tool.
Conference Paper
Full-text available
The lack of well-founded constructs in ontology tools can lead to the construction of non-intended models. In this demonstration we present the Menthor Editor, an ontology-driven conceptual modelling platform which incorporates the theories of the Unified Foundational Ontology (UFO). We illustrate how UFO categories can improve the design of domain ontologies. Moreover, the verification and validation approaches are demonstrated with ontologies of our catalogue. The complete execution of the model-driven engineering is exemplified, including situation modelling.
Conference Paper
Full-text available
Enterprise information systems are increasingly being conceived as a combination of existing systems and to work as a part of an ecosystem of software products. This change demands methods and tools to deal with the challenging semantic interoperability issues. OntoUML is a well-founded modeling language that allows modelers to formalize world-views in a technologically neutral way, aiding in the solution of such interoperability challenges. In this paper, we present an overview of the OntoUML Lightweight Editor (OLED), our model-based environment to build, evaluate and implement OntoUML models, alongside with its main features and application scenarios.
Conference Paper
Full-text available
This paper proposes a principled approach to the definition of real-world semantics for declarative domain-specific languages. The approach is based on: (i) the explicit representation of the admissible states of the world through a reference domain ontology (which serves as semantic foundation for the domain-specific language), (ii) a representation of the valid expressions of a domain-specific language (to determine the abstract syntax of the language), and (iii) the rigorous definition of the relation between the abstract syntax and the reference domain ontology (to define the real-world semantics of the language). These three elements of the approach are axiomatized in three corresponding logic theories, enabling a systematic treatment of real-world semantics , including formal tooling to support language design and assessment.