Conference PaperPDF Available

Ontology-Based Information System

Authors:
  • Institute of Mathematics and Computer Science University of Latvia

Abstract and Figures

We describe a novel way for creating information systems based on ontologies. The described solution is aimed at domain experts who would benefit from being able to quickly prototype fully-functional, web-based information system for data input, editing and analysis. The systems backbone is SPARQL 1.1 endpoint that enables organization users to view and edit the data, while outside users can get read-only access to the endpoint. The system prototype is implemented and successfully tested with Latvian medical data ontology with 60 classes and imported 5 000 000 data-level triples.
Content may be subject to copyright.
Ontology-Based Information System
Martins Zviedris, Aiga Romane, Guntis Barzdins, Karlis Cerans
Institute of Mathematics and Computer Science, University of Latvia
Raina blvd. 29, Riga, LV-1459, Latvia
E-mail: {martins.zviedris, guntis.barzdins, karlis.cerans}@lumii.lv, aiga.romane@inbox.lv
Abstract. We describe a novel way for creating information systems based
on ontologies. The described solution is aimed at domain experts who would
benefit from being able to quickly prototype fully-functional, web-based
information system for data input, editing and analysis. The systems backbone
is SPARQL 1.1 endpoint that enables organization users to view and edit the
data , while outside users can get read-only access to the endpoint. The system
prototype is implemented and successfully tested with Latvian medical data
ontology with 60 classes and imported 5 000 000 data-level triples.
Keywords: OWL ontology, SPARQL, Instance Editing, Prototyping
1 Introduction
J.F.Sowa proposed that “Every software system has an ontology, implicit or explicit”
[1]. It means that every software system is created to work with a knowledge base that
can be described using ontologies and it may be possible to create an information
system based on a formal ontology.
In our work we perceive the ontology definition as two separate parts. First is the
factual part (Abox or ontology schema) that includes known facts about a knowledge
base, for example, a statement that some individual is Person. In the presented paper
we mainly focus on this part.
Second (Tbox or ontology instances) are the reasoning and constraint rules for the
factual part, for example, a rule "if an individual is male and has children then he is a
father" or a constraint that a person can have only two parents. We see that partly
these rules can be done using SPARQL queries, but this is out of this paper’s scope.
We describe a novel way to build a simple information system from an OWL [13]
ontology. The presented tool automatically generates a fully-functional data storage
and retrieval type information system based on a given ontology’s RDFS schema part.
The result is a web-based platform for editing and overlooking ontology knowledge
base. The main focus of our work is on user friendliness of information system
creation process rather than on advanced features of the system.
Additional system configuration options allow one to add more complicated
features later on, but that is outside the scope of this paper. The approach is called an
ontology-based information system (OBIS).
The core of our system is based on the factual part where a user edits information
about individuals their attribute values and classes they belong to. For now, OBIS
uses the RDFS subset of ontologies named classes, properties and associations
between them, and subclass hierarchies. This subset corresponds to the inference
capabilities of the underlying SPARQL endpoint that we use1.
We envision that the proposed approach can be used for semantic system
development for small organizations as they often describe information systems as
expensive and hard to maintain and resort to, for example, large Excel files instead.
Instead they would only need an ontology describing their domain, which would
allow them to create the information system required.
For example, it would be great to access one’s hairdresser's schedule to know when
he or she is available. Providing hairdressers ontology one can create automatically
the system. Thus, the hairdresser’s workers edit information when they are available
and when they are occupied. Clients (or client agent) access system (or SPARQL
endpoint) in read-only access to see available spots or even register to the hairdresser.
This is one step towards the Semantic Web original idea about agents [10].
The described OBIS prototype is available at http://obis.lumii.lv.
2 Use Case of the OBIS Methodology
In this section we describe the process how a typical user would create and use the
ontology-based information system.
2.1 Selecting or Creating an Ontology
To build an OBIS information system one needs an OWL ontology that describes the
conceptual structure of the data to be held in the information system. One can search
ontology repositories (e.g., the DERI vocabulary catalogue2) or the Web for an
appropriate ontology, or one can create an ontology from scratch.
For illustration purposes we will create an information system for a veterinary
clinic. As we did not find a suitable ontology we created a simple ontology depicted
in Fig. 1 using the OWLGrEd editor [3]. The ontology could have been created in any
other ontology editor, for example, Protégé3.
Ontology consists of all doctors that work in a clinic. Doctors hold appointments
that can be classified in two subclasses: planned and past appointments. For each
appointment there is an animal to be examined. For past appointments there are also
details about performed examinations and their types.
1 We use Virtuoso (http://virtuoso.openlinksw.com/) endpoint which implements RDFS
reasoning and supports SPARQL 1.1. We considered StarDog endpoint with full OWL
reasoning, but it does not support SPARQL 1.1 update.
2 http://vocab.deri.ie/
3 http://protege.stanford.edu/
Fig. 1. Veterinary clinic ontology
2.2 Creating a New Ontology-Based Information System
After the ontology is selected or created we can proceed with generating a new
information system. This task is very simple as we just need to open the system
generator in a web browser and upload the ontology, see Fig. 2. The OBIS tool will
generate a working information system that is available through web browser for data
browsing and editing.
The generated OBIS information system uses a preselected (in the OBIS
generation tool the creator enters the SPARQL endpoint address) SPARQL endpoint
for data storage; the data in this endpoint is also available to other tools.
The generated user interface is quite simple there is a header, a tree-like menu
with a list of all pages and a content frame (see Fig. 3). The information system has a
page for each class in the ontology, listed in the page menu. The content part allows
users to view, edit and create new class instances.
Fig. 2. The OBIS generation tool
2.3 Using the Created Information System for Data Manipulation
The data manipulation takes place in the content frame of the information system’s
web interface. It is similar to a database entry manipulation in other information
systems, for example, MS Access. Users can click on a class in the tree menu that
they want to inspect at the instance level.
Figure 3 depicts the browsing view of a selected class. It displays all individuals of
the selected class in a table format. A user can browse, sort or filter individuals by
data property (attribute, column) values. If the user selects one individual (instance,
row) then a detailed browsing/editing window for that individual (instance) is opened.
Fig. 3. A list of class instances in a table form
Figure 4. shows the individual (instance) data browser. Its upper part displays the
individual's (instance) data properties (attributes) and their respective values. Below it
lists all the outgoing and incoming4 object properties (connections, associations) and
individuals (instances) they connect to are displayed.
Thus, a user can easily add, update and delete instances for all classes in the
ontology. This is done using the SPARQL 1.1 protocol and with data being stored in
the underlying SPARQL endpoint 5.
Fig. 4. The individual data browser
2.4 Report browsing
One of the most important parts of relational databases is the view definition
mechanism. It allows to create various, more complex looks on the underlying data.
This is important in any information system.
We consider it an important part of OBIS, as well. However, we want to extend
this view mechanism to allow navigating from any individual description that is
included in a view further to the individual’s details.
To achieve this result, we define the requirements of view creation. Each view
must have defined one central class. In OBIS, the view is a SPARQL query where a
specific variable binding (?ID) is used to identify individuals of the central class. It is
also permitted to include in the view additional attributes from connected individuals
by connecting them in the SPARQL query. In order to include the defined view in the
hierarchy of ontology classes offered by OBIS, one would create a named subclass of
the view’s central class and annotate it with the SPARQL query describing the view.
Alternatively, one could dynamically load the SPARQL queries corresponding to
the views into OBIS system via its explicit report mechanism that offers the SPARQL
4 Although inverse object properties are available in OWL, their inference is not supported by
SPARQL endpoint such as Virtuoso. Therefore, it is more convenient to allow navigating
object properties bi-directionally.
5 We use Virtuoso endpoint - http://virtuoso.openlinksw.com/
query execution to obtain the result set that is enriched with navigation to every
report’s line central entity details’ pages.
This feature is most useful for data browsing. If we run the OBIS in read-only
version for enterprise clients then it would also be useful to define additional views to
enable end users to understand the underlying data better.
For example, we would like to add a report view for Animal class to OBIS based
on the veterinary ontology depicted in Fig. 1. The report contains all information
about an animal including animal species name that is stored in a separate class
Species.
SPARQL query defining the view is depicted in Fig. 5 while the report view of the
information system is depicted in Fig. 7. This report is named “AnimalSpecies” and is
highlighted with a different icon in the tree list.
SELECT DISTINCT
?ID ?Animal__animalName ?Animal__breed
?Animal__ownerName ?Species__speciesName
WHERE {
?ID rdf:type :Animal.
OPTIONAL { ?ID :animalName ?Animal__animalName.}
OPTIONAL { ?ID :breed ?Animal__breed.}
OPTIONAL { ?ID :ownerName ?Animal__ownerName.}
?ID :isASpiecies ?Species.
?Species rdf:type :Species
OPTIONAL { ?Species :speciesName
?Species__speciesName.}}
Fig. 5. SPARQL code to define view
Fig. 6. ViziQuer lite query defining the report
Fig. 7. Preview of report table view
2.5 SPARQL endpoint access
All data is stored in the SPARQL endpoint, thus it can be accessed by SPARQL
queries or by other tools that visualize or gather data from a SPARQL endpoint.
Automatic data agents could also access the SPARQL endpoint.
An example of an application that can connect to the SPARQL endpoint is the
ViziQuer6 graphical SPARQL language front-end [4]. The ViziQuer tool can also be
used for report creation as it gives end-users a simple and visual way to create
SPARQL queries. For example, the query in Fig. 5. corresponds to the ViziQuer
graphic query shown in Fig. 6.
Finally, the OBIS graphical interface can be used in a read only mode for data
browsing by enterprise clients via web interface.
3 OBIS overview
We can perceive the ontology definition as two separate parts. First is the factual part
(Abox or Assertion box) that includes known facts about our knowledge base, for
example, a statement that some individual is Doctor. Second (Tbox or Terminology
box) is the reasoning and constraint rules for the factual part, for example, a rule "if
time of an appointment is earlier that today then it must be past appointment" or a
constraint that an appointment has just one animal to examine.
As the users at first need to enter the data into the system then our core focus now
is based on the factual part where a user edits information about individuals. For now,
OBIS uses the RDFS subset of ontologies named classes, properties and
associations between them, and subclass hierarchies as it covers all necessity to work
with data input and editing.
Named class instances in the ontology are edited through OBIS interface. The class
instance assertions for anonymous restriction classes are derived implicitly from the
individual’s properties and can be checked e.g. using SPARQL queries and non-
editable views, similar to those described in subsection 2.5.
We see that reasoning and constraint rules are an important part of the ontology. It
helps to maintain correct and consistent input, and also reveals which classes
individuals belong to. We envision that a part of constraints could be enforced on
client side (for example, checking of simple input constraints, cardinality) while
another part could be performed in server side. Obvious implementation would be to
translate OWL constraints to SPARQL queries that would allow monitoring data
integrity regularly as is done in similar works [11].
An essential part of OBIS is its ability to show the instances of a class together
with their data property values in a tabular form thus obtaining a compact overview of
a list of class instances at the same time. The key assumption behind the possibility of
the - OWL data property cardinality is restricted to 1, which allows data properties of
individuals to be visualized as a table or a data input form that is typical for traditional
information systems. We use this restriction only for now to make the system a bit
6 http://viziquer.lumii.lv
simplistic and easier to explain and more performance-efficient. In the future we plan
to use SPARQL 1.1 aggregate feature GROUP_CONCAT to show all values comma
separated in one table cell or to adapt some other understandable display form.
The architecture of our solution is depicted in Fig. 8 We divide it in three main
parts (i) an ontology that represents a factual data structure, (ii) an OBIS
information system that is generated from the data ontology and can be used by
enterprise workers for data editing and (iii) SPARQL endpoint for enterprise clients
that allows them to gather meaningful data and that can be accessed via different
tools, for example, the OBIS information system in a read-only version.
Fig 8. System architecture
We note that the implementation described here is truly model driven every OBIS
information system is viewed as a set of instances of the universal OBIS meta-
ontology, see Fig. 10.
The OBIS generation tool loads the data ontology and generates from it a set of
instances of the OBIS meta-ontology. The resulting set of OBIS meta-ontology
instances is afterwards executed by the interpreter that provides that every OBIS
information system is presented as a composition of web-pages, see Fig. 9. The
appearance of the automatically generated OBIS meta-model instance can later be
customized for each enterprise.
The OBIS interpreter effectively presents the generated OBIS information system
as composition of webpages. It is a web-based system where one can browse through
pages and see all class instances, edit them and add new ones. The data is stored and
updated in an SPARQL 1.1 endpoint.
Every enterprise customer can query the SPARQL endpoint in a read-only mode
and retrieve information that interests them. A user can access the SPARQL endpoint
in a read-only mode by various tools, including read-only OBIS information systems,
ViziQuer [4] or other data agents. In this paper we do not discuss the question of
information privacy or sensitivity.
If we look back at one of the initial ideas of the Semantic Web [10] then a major
role was meant for agents that could gather data and make suggestions to a user. By
means of the OBIS system’s SPARQL endpoints it could be one step closer to
achieving the idea about agents gathering information.
Thus, we are effectively combining the mentioned Sowa’s statement with Model
Driven Architecture [2] approach that says that it is possible to develop universal
platform independent meta-model (PIM or OBIS meta-ontology). Any specific
instance of this platform independent meta-model can be converted to executable
program (sometimes referred to as platform specific model or PSM or OBIS
interpreter).
4 Technical implementation
The described implementation is based on the model driven approach every OBIS
information system is viewed as a set of instances of the universal OBIS meta-
ontology, see Fig. 10.
Web Application Builder (the OBIS generation tool) uses a data-ontology to
generate the instance-data of the OBIS meta-ontology, see Fig. 9. Afterwards the Web
Application Runtime Engine interprets this OBIS meta-ontology instance-data to
provide the OBIS information system that is used by end-users through a web
browser.
Fig. 9. High-level OBIS workflow architecture
OBIS meta-ontology (Fig.10) captures the common standard functionality of a typical
web information system consisting of:
Data representation and processing;
Display of user interface components - web pages, data forms, tables, menus,
images, etc.;
Client and server side validation rules;
Navigation between web pages and between web page components;
Application user management (authentication and authorization);
Reporting.
This ontology is used as the backbone of the OBIS and enables the truly model-driven
design principle detailed here.
Web Application Builder is responsible for building an OBIS information system.
In terms of model driven approach, this means to fill the OBIS meta-ontology with
required instance-data based on user’s data-ontology.
Besides fully automatic web application generation mode, this component provides
also some configuration possibilities such as adjusting visual layout of components on
the web page or other adjustments permitted within the OBIS meta-ontology.
The Web Application Builder is created as GWT8/GXT9 web application with Java
on server side. It reads data ontology file (RDF/XML syntax) using JENA parser10.
Fig. 10. OBIS meta-ontology
Web Application Runtime Engine is the OBIS interpreter executing an OBIS
information system during runtime. It:
reads previously created OBIS meta-ontology instance-data file and
interprets it;
maps OBIS meta-ontology instance data to corresponding GWT/GXT user
interface components;
8 GWT (Google Web Toolkit) - https://developers.google.com/web-toolkit/
9 GXT (Google Extended Toolkit) - http://www.sencha.com/products/gxt
10 http://jena.apache.org/
processes user input/output requests based on information in the OBIS meta-
ontology instance data (processing includes client side form field validation,
report creation, data representation and processing).
On a more detailed level Web Application Runtime Engine is a GWT/GXT web
application with Java on server side. It can be deployed on Java compatible web
application servers11 such as Tomcat 7.0.
The main component of Web Application Runtime Engine is the Web Application
Ontology Reader. Rather than using Jena API or similar tools, it reads and translates
OWL file with OBIS meta-ontology instance data directly into Java class instances
OWL individuals are mapped directly into Java class instances. Thus, we actually
make PIM to PSM transformation, an insight about PIM to PSM process can be
gained in [14].
Such OWL/Java class and individual/instance mapping is made possible by
predefined OBIS meta-ontology being a 1:1 copy of Java class hierarchy within the
Web Application Ontology Reader component (This actually is platform independent
to platform specific model transformation).
To facilitate such mapping, Java class structure is annotated with semantic types
and reader automatically maps OWL XML (the reader reads OBIS meta-ontology as
XML document) tags to annotated Java classes, see table 1. Semantic annotations also
include class or property names they correspond to in the OBIS meta-ontology.
Currently semantic annotations cover only a small part of RDF/OWL but they can be
extended if needed.
Table 1. OWL to Java mapping annotations
OWL XML tag
JAVA element
owl:Class
class
owl:DatatypeProperty
class internal variable with
primitive data type (String,
Integer, etc.)
owl:ObjectProperty
class internal variable with
reference data type (points to
other class)
This OWL to Java mapping approach has been developed specifically for our system,
but is not limited to web application ontology it can actually be used with any meta-
model ontology and corresponding Java class hierarchy.
We choose such architecture for performance reasons as this effectively creates a
compiled runtime rather than interpreted runtime. This is important for interactive
systems, as end-users want to see their action results immediately.
Other Web Application Runtime Engine software components are:
UI Generator - maps OBIS meta-ontology instance-data to corresponding
GWT/GXT user interface components;
11 http://tomcat.apache.org/
Application Controller - handles user requests (browser events) and executes
appropriate services (save, search, login, etc.) and displays results;
RDF Repository Service - provides CRUD operations with Virtuoso RDF
server;
Rule Engine - executes validation rules on form fields;
Report Engine - generates report queries and displays results in GWT/GXT
tables with possibility to save in MS Excel.
The components listed above interact in the following way. The main entry point is
invoked by GWT/GXT when web application is opened from a web browser for the
first time. This entry point calls server side method, which reads OBIS meta-ontology
instance-data using Web Application Ontology Reader (described above).
As a result a Java class instance hierarchy is returned, populated with data from
OBIS meta-ontology instance-data. App entry point then calls UI Generator which
creates GWT/GXT widgets.
The UIGenerator is invoked on request, i.e. new web page is created only after user
has requested it (e.g., a user pressed a link/button which navigates to another page).
Every web page consists of components which can be just display objects or can
call some service. WebPage in OBIS meta-ontology is mapped to the GXT
component LayoutContainer. WebPage invocation adds all subcomponents to this
container as GWT/GXT widgets, which are automatically gathered from OBIS meta-
ontology represented by the Java class hierarchy.
Web Application Runtime Engine logic is split into two modules communicating
through GWT/GXT asynchronous calls:
client services package (displays UI and handles UI input/output requests)
server services package (calls other server-side services or third-party
libraries, for example, Virtuoso RDF API).
All data is stored in a Virtuoso RDF database, which the Web Application Runtime
Engine communicates with using SPARQL 1.1, as it provides both SPARQL select
and update. Virtuoso RDF database also provides a public SPARQL endpoint that can
be used by other systems.
5 Evaluation
The OBIS was evaluated as a part of a linguistic research project at the University
of Latvia, where it was used for navigating and editing FrameNet12 data while
adapting it from English to Latvian language.
The need for the OBIS-like fast prototyping solution was dictated by frequent
database structure changes requested by linguists. It would have been arduous to
manually adapt the information system structure and interface every few days as
linguists came up with new ideas for improved data structure (ontology).
Attempts to use a universal Protégé-like ontology individual editor interface for the
frequently changing information system were not successful, as it turned out that
12 http://framenet.icsi.berkeley.edu
linguists were thinking in terms of "tables" rather than RDF graphs - just like most
relational SQL DB users and even programmers do. Thus creating good table-like
views on ontology individuals became the focus of the OBIS development team.
It is relatively straightforward to create a table of individuals belonging to the
selected class and to display data property attributes of each individual in additional
columns of the table. But such simplistic approach turned out to be insufficient for the
needs of linguists - they wanted to see in the same table not only data properties of the
selected class, but also data properties of some individuals in neighboring classes,
linked through object properties. This requirement lead to incorporation of arbitrary
SPARQL queries as a way to generate arbitrary table-views on the data.
But even this solution turned out to be insufficient for the needs of linguists - they
wanted these table-views to be easy to edit in case some errors in the data were
spotted (regular SPQRQL-generated reports are not editable). A solution was found
how to make these SPARQL generated table-views editable - each SPARQL query
must be associated with some "central class" individuals that this query is selecting
(meanwhile the same query may also select individuals and attributes from other
classes).
In this way each row in the SPARQL-generated answer table can be linked to the
URI of the corresponding individual from the "central class" of the SPARQL query;
by clicking on any row in the query answer table the system can automatically
navigate to the corresponding individual of the “central class”. From there the user
can easily navigate to the attribute he wants to edit - it is either an attribute of this
individual, or one of its neighboring individuals linked through object properties.
Since such “editable” SPARQL query generated table-views became integral part
of the ontology based information system, it became natural to store them as
annotations in the data ontology along with the “central class” they belong to. From
there OBIS can automatically retrieve these queries and present them to the user as
“editable” tables-views as part of the special leaves in the class-tree menu.
As a result of these improvements OBIS met the requirements of the linguistic
research project and evolved into the universal approach described in this paper.
To test OBIS performance on larger data sets we loaded Latvian medical data into
SPARQL endpoint and generated the OBIS information system from the Latvian
medical ontology described in more details in [12]. Overall there are around 60
classes and more than 300 000 individuals in the ontology. The OBIS information
system worked fine, although loading time for the Person class that has more than
70000 records took around 30 seconds.
Additional evaluation was conducted regarding convenience of the ViziQuer tool
as a way to create SPARQL queries associated to some "main class". Original version
of ViziQuer [4] did not use the concept of “main class” during SPARQL query
construction. To adapt to OBIS needs a ViziQuer Lite version was created with “main
class” concept at the center. ViziQuer Lite was further refined and usability
improvements of these refinements were evaluated through blind tests conducted
through Amazon Mechanical Turk.
6 Related work
We position our platform as a fast way to deploy an information system from an
ontology. A similar tool from the functionality perspective is WebProtégé [5].
Main difference is that WebProtégé focuses on collaborative ontology editing; our
focus is on collaborative instance data editing. WebProtégé tool also allows editing on
the instance level of the ontology, but it does not enforce data property cardinality
restriction to one. Thus, it is hard to overview all the created individuals as they are
listed by their identifier only, while the rest of properties are scattered.
WebProtégé presents a way to create individuals through custom forms, but
individual creation form specification must be given in a XML specification file
written by hand. Another drawback of WebProtégé is that it does not interface with a
public SPARQL endpoint.
Also it does not separate ontology editing from instance editing, as it is important
part in information systems. It is normal that data conceptual model can be edited
only by system’s administrator, but system data editing is done by enterprise common
users. WebProtege does not separate browsing capabilities from editing capabilities.
In contrast, our system provides an SPARQL endpoint access point where one can
connect from outside in browsing mode or by read-only OBIS information system.
Tools like OntoViews [6], Longwell [7] allow users to browse semantic data in
faceted manner. There are lot of options from browsing side point of view, but these
tools do not provide capability to edit the underlying data.
Koodl13 provides a user with collaborative ontology editing, connection to a
SPARQL endpoint, creating and editing SPARQL queries, visualizing and analyzing
created results. This approach also is based on data browsing and analyzing, not
editing.
Another similar tool is OntoWiki [8] that is proposed as collaborative ontology
data editor and it targets mostly instance data browsing and editing. It also provides
access to data by SPARQL queries. New version is stated to incorporate a visual
query builder [9]. As in wiki it does not strictly enforce ontology structure for
instance data ontology serves more like a dictionary. Individuals can have
properties that are not defined in the ontology.
In relation database field there exist different solutions that ease web-based
application building from a database (Oracle APEX14, SQL Maestro15). Still, we did
not encounter one that would fully automatically generate a working system from the
given database.
13 http://knoodl.com
14 http://apex.oracle.com/
15 http://www.sqlmaestro.com/
7 Conclusions and Future Work
We have successfully implemented and tested the ontology-based information
system (OBIS) development process. The first results are good, which is supported by
our linguistic application test case in case of usability experience. The experiment
with the medical data provides evidence that the system can scale up to larger data
sets and is usable in real world applications.
We still see room for further development and technical realization. Important
aspect that we have not targeted is how to move an individual (instance) from one
class to another class or manipulate list of classes where the individual belongs. In our
example of veterinary clinic it is natural to move planned appointments to past
appointments. For information systems used over prolonged periods of time it is
typical requirement. For example, a student becomes a professor; a prospect becomes
a customer, etc.
We see that reasoning and constraint rules are an important part of the ontology. It
helps to maintain correct and consistent input, and also reveals which classes
individuals belong to. We envision that a part of constraints could be enforced on
client side (for example, checking of simple input constraints, cardinality) while
another part could be performed in server side. Obvious implementation would be to
translate OWL constraints to SPARQL queries that would allow monitoring data
integrity regularly as is done in similar works [11].
There are named classes, which instances are edited through OBIS interface.
Another part is restriction classes that are defined using OWL rules, for example,
equivalent to the union of two classes. We envision that this part would also translate
into SPARQL queries. The result of the translation could be perceived as a non-
editable view similar to those described in subsection 2.4.
We see that the OBIS can be successfully used for web-based SPARQL endpoint
data access and editing to promote the Semantic Web usage in wider user base.
8 Acknowledgments
Mārtiņš Zviedris has been supported within the European Social Fund Project
Support for Doctoral Studies at University of Latvia - 2”. Aiga Romāne and Kārlis
Čerāns have been supported by the European Union via European Regional
Development Fund Project No. 2011/0009/2DP/2.1.1.1.0/10/APIA/VIAA/112. Guntis
Bārzdiņš has been supported by Latvian 2010.-2013. National Research Program Nr.2
project Nr.5.
References
1. Sowa J.F., (2011), Serious Semantics, Serious Ontologies, panel presented at Semantic
Technology Conference (SEMTEC 2011), San Francisco
2. Soley R, (2000), Model Driven Architecture. OMG white paper
3. Barzdins J., Barzdins G., Cerans K., Liepiņs R., Sprogis A., (2010), OWLGrEd: a UML
Style Graphical Notation and Editor for OWL 2. In: Clark, K., Sirin, E. (eds.) Proc. 7 th
International Workshop “OWL: Experience and Directions” (OWLED-2010)
4. Zviedris M., Barzdins G., (2011), ViziQuer: A Tool to Explore and Query SPARQL
Endpoints, The Semantic Web: Research and Applications, LNCS, 2011, Volume
6644/2011, pp. 441-445
5. Tudorache T., Nyulas C., Noy N., Musen M., (2012), WebProtégé: A collaborative
ontology editor and knowledge acquisition tool for the web. Semantic Web Journal, pages
1–11.
6. Makela, E., Hyvonen, E., Saarela, S., Viljanen, K.: (2004) OntoViewsa tool for cre-
ating semantic web portals. In: Proceedings of 3rd International Semantic Web
Conference (ISWC 2004), Hiroshima, Japan, SpringerVerlag
7. Longwell RDF Browser, SIMILE (2005). http://simile.mit.edu/longwell/
8. Auer S., Dietzold S., Riechert T., (2006). OntoWiki A Tool for Social, Se- mantic
Collaboration. In In Proceedings of the 5th International Semantic Web Conference,
ISWC2006, volume 4273 of LNCS. Springer
9. Riechert T., Morgenstern U., Auer S., Tramp S., Martin M., (2010) Knowledge
engineering for historians on the example of the catalogus professorum lipsiensis in
ISWC2010, ser. LNCS. Shanghai / China: Springer.
10. Berners-Lee T., Hendler J., Lassila O. (2001) The Semantic Web. Scientific American.
11. Tao, J., Sirin, E., Bao, J., McGuinness, D.L (2010) Integrity constraints in OWL. In: Fox,
M., Poole, D. (eds.) Proc. of the 24th AAAI Conference on Artificial Intelligence, AAAI
2010. AAAI Press
12. G.Barzdins, E.Liepins, M.Veilande, M.Zviedris, "Semantic Latvia Approach in the
Medical Domain", Proceedings of the 8th International Baltic Conference (Baltic DB&IS
2008), June 2-5, Tallin, Estonia, Tallinn University of Technology Press, 89.-102. pp.
13. Motik, B; Patel-Schneider P.F; Parsia B.: OWL 2 Web Ontology Language Structural
Specification and Functional-Style Syntax, 2009
14. Escalona Ma J, Aragón G. NDT a model-driven approach for web requirements. IEEE
Trans Softw Eng 2008;34(3):37790.
... The practical working solution of the Medicine Registries example have been achieved via generated D2RQ mapping with the source data residing on the Microsoft SQL Server. It has been possible to explore the generated SPARQL endpoint both in the ad hoc mode by the ViziQuer tool [25,15,16] and in browsing mode by the OBIS tool [26] within the relational database semantic re-engineering framework described in [19]. The usage of D2RQ tool both in on-the-fly SPARQL endpoint creation and in the RDF dump mode with the RDF data loaded further on into the Virtuoso server have been considered with the better runtime performance achieved with the data stored within Virtuoso server. ...
... Although the RDB2OWL tool has a well-defined task of creating a conceptuallevel SPARQL endpoint for a relational database, permitting its standalone use, a particular usage context of the RDB2OWL database-to-ontology mapping tool is within a larger semantic database platform involving also the OWLGrEd ontology editor [21,22], the visual custom SPARQL query generation tool ViziQuer [25,15,16] and the SPARQL endpoint browser OBIS [26]. ...
Conference Paper
We describe the RDB2OWL Lite language for relational database to RDF/OWL mapping specification and discuss the architectural and content specification patterns arising in mapping definition. RDB2OWL Lite is a simplification of original RDB2OWL with aggregation possibilities and order-based filters removed, while providing in-mapping SQL view definition possibilities. The mapping constructs and their usage patterns are illustrated on mapping examples from medical domain: medicine registries and hospital information system. The RDB2OWL Lite mapping implementation is offered both via translation into D2RQ and into standard R2RML mapping notations.
... The currently available extensions include: 1) OWLGrEd_UserFields, historically the first extension [11], part of default OWLGrEd configuration, providing the basic mechanisms of both creation and run-time support for custom information fields and ontology presentation views; 2) RefactoringServices, supports transformations among ontology element visual presentation options (e.g. an object property presentation can be switched between the graphical and textual form); the transformations are added to the context menus of the ontology diagram elements to be transformed; 3) OWLGrEd_Schema, a novel (work in progress) extension supports assertions of a property applicability within a given class context; the property domain is then computed as the union of all classes for which the property is applicable (cf. Fig.2); 4) OWLGrEd_OBIS, supports the annotation framework [15] for automated ontology-based information system generation [16]. Parts of it have been also refactored into separate extensions, including UML_Plus (introduction of UMLstyle elements for modeling notation: a composition, an enumerated class, an abstract class and a derived property) and DefaultOrder (recording of attribute ordering information within a class node). ...
Chapter
OWLGrEd is a visual editor for OWL 2.0 ontologies that combines UML class diagram notation and textual OWL Manchester syntax for expressions. We review the basic OWLGrEd options for ontology presentation customization and consider the framework of OWLGrEd extensions that enables introducing rich use-case specific functionality to the editor. A number of available OWLGrEd extensions offering rich ontology management features to their end-users are described, as well.
... We can note that the equivalent class assertions for the subclasses of the Teacher class are " enforced " by the RDB2OWL mapping definition; while the facet restrictions in the current mapping version are left to be checked as constraints over the obtained RDF triple set. Although the RDB2OWL tool has a well-defined task of creating a conceptuallevel SPARQL endpoint for a relational database, permitting its standalone use, a particular usage context of the RDB2OWL database-to-ontology mapping tool is within a larger semantic database platform [15] involving also the OWLGrEd ontology editor [16,17], the visual custom SPARQL query generation tool ViziQuer [20] and the SPARQL endpoint browser OBIS [21]. ...
Conference Paper
Full-text available
We demonstrate a high-level RDB2OWL language for database-to-ontology mapping specification in a compact notation within the ontology class and property annotations, as well as a corresponding mapping implementation tool that translates the RDB2OWL mappings into executable D2RQ mappings thus allowing to create a semantic SPARQL endpoint containing conceptually organized data from a relational database.
... We structure the presentation into two main sections – first is explained the basic OBIS application generation, followed by application tuning possibility description. The conceptual foundation of the OBIS system has been described in [15], the current paper reports on new basic functionality (e.g. related items view), as well as entirely new ontology annotation framework. ...
Conference Paper
Full-text available
We demonstrate a framework for automated information system generation from a given data ontology describing either an existing data set, or a data set to be filled up and maintained using the created information system. The IS data are stored into real or virtual RDF data stores and are accessed by means of SPARQL queries. The data ontology structure information and annotations allow automated generation of IS reflecting the data structure specified in the ontology.
... Such software is then no more than a tool for ontology browsing and concept instantiating. Ontology Based Information System (OBIS) [30] is an example of such an approach. ...
Conference Paper
Full-text available
Recent developments in the area of Internet of Things increase the pressure on the feasibility of current architectures of the Enterprise Information Systems (EIS), in terms of their complexity, flexibility and interoperability in a pervasive computing world. The fact that EISs are today hosted by the growing diversity of platforms and devices, urges as to consider new concepts that would take into account rapid deployment and setup in any circumstances. This paper presents the discussion of modeldriven architectures and proposes the concept of EIS design that is ontology-driven, persistence-neutral, runtime-modelbased. These concepts are to some extent demonstrated in the case of OntoApp tool for ontology scaffolding.
Thesis
Full-text available
This thesis presents three applications that have been designed, developed and deployed in real use cases for Hydro-Quebec, the Quebec provincial producer, carrier and supplier of electricity. These applications were created in such a way as to exhibit properties of selfadaptability to the evolution of knowledge of the company. The objective of this applied research was to assess the feasibility of using semantic web technologies to create such web applications that are usable by novice users. The development of these three applications resulted in contributions specific to each of them. The first application is a textual semantic browser and it has demonstrated that it is possible to achieve conceptual independence thanks to semantic web technologies. The second application is a SPARQL visual query builder. Its development has mainly enabled the exploration of the transposition of functionalities associated with the construction of SQL queries to the SPARQL language. The third application is a view builder taking advantage of the lessons learned during the realization of the two previous applications. The contributions associated with this application include: 1. A unique software component for ontological exploration; 2. A list of ontological modeling recommendations allowing models to be used by applications applying this methodology; 3. A visualization ontology which is a first attempt towards the creation of a standard in order to guide and personalize user interfaces by annotations made within domain ontologies; 4. A set of pre-inferences allowing reconciliation of the concept of inheritance in object-oriented paradigms with the concept of classification of the paradigm of first-order logic; and 5. An approach for crossing data from OWL ontologies in an ad hoc manner. The experiments presented in this thesis made it possible to develop a methodology to generate self-adaptive applications maneuverable by neophytes, thus filling a gap in the literature. The feasibility of such an approach has been proven by the release of the third application, generated using this methodology, into the company's systems. This research suggests that such applications could lead to reduced software development and maintenance costs. In addition, the genericity and self-adaptability of the tools developed make this approach a prime candidate for the development of Industry 4.0 applications.
Chapter
End-user interaction with data is one of key aspects in data processing. Nowadays a lot of information systems have a custom made user interface for data input and data querying. From 1970s it is envisioned that a generic, user-friendly approach for data querying could be built, but no wide spread solution has been developed. In the paper we present a diagrammatic query language. We have done an iterative approach to design and improve the diagrammatic query language to make it user readable. Readability is analyzed with questionnaires. Readable diagrammatic query language is the first step to create a more generic and user-friendly data querying.
Article
Full-text available
Two years ago we presented a unified conception of "Semantic Latvia" which would make it possible for a small country like Latvia to take advantage of the emerging Semantic Web technologies. In this paper we show how this approach is starting to materialize into a real application in the domain of national Medical databases thanks to the important technological gap filled by the UML profile for OWL. Discussed is the data export from multiple relational databases into a single shared RDF database structured according to an integrated OWL ontology. The exported data is conveniently accessible via SPARQL or via graphical query language based on UML profile for OWL. The approach is demonstrated on two Latvian Medical databases – Oncologic Disease register and Trauma/Injury register.
Article
Full-text available
Since its inception, the Object Management Group (OMG) has provided vendor-and language-independent interoperability standards to the enterprise. The CORBA (Common Object Request Broker Architecture) standard has recently been modified for --and embraced by --environments that require specialized real-time, fault-tolerant, and embedded systems. The OMG's complementary core modeling specifications include the Unified Modeling Language (UML), the Common Warehouse Meta-model (CWM), the Meta-Object Facility (MOF), and XML Metadata Interchange (XMI). Now, the OMG is building on the success of CORBA and the UML to take aim at the problems arising from the proliferation of enterprise middleware. Its Model Driven Architecture (MDA) initiative champions the extensibility and reliability of CORBA while acknowledging that enterprises cannot simply abandon their investment in other technologies. (More on MDA can be found at www.omg.org/mda) Rational Software has been particularly active, along with many other OMG member companies, in contributing ideas and principles toward the creation of MDA. If you are a Rational customer interested in modeling or software development infrastructure, I think you'll be interested in the OMG's concepts, goals, and plans for MDA, as described in the following article.
Article
Full-text available
In this paper, we present WebProtégé-a lightweight ontology editor and knowledge acquisition tool for the Web. With the wide adoption of Web 2.0 platforms and the gradual adoption of ontologies and Semantic Web technologies in the real world, we need ontology-development tools that are better suited for the novel ways of interacting, constructing and consuming knowledge. Users today take Web-based content creation and online collaboration for granted. WebProtégé integrates these features as part of the ontology development process itself. We tried to lower the entry barrier to ontology development by providing a tool that is accessible from any Web browser, has extensive support for collaboration, and a highly customizable and pluggable user interface that can be adapted to any level of user expertise. The declarative user interface enabled us to create custom knowledge-acquisition forms tailored for domain experts. We built WebProtégé using the existing Protégé infrastructure, which supports collaboration on the back end side, and the Google Web Toolkit for the front end. The generic and extensible infrastructure allowed us to easily deploy WebProtégé in production settings for several projects. We present the main features of WebProtégé and its architecture and describe briefly some of its uses for real-world projects. WebProtégé is free and open source. An online demo is available at http://webprotege.stanford.edu.
Conference Paper
Full-text available
There have been several attempts to visualize OWL ontologies with UML style diagrams. Unlike ODM approach of defining a UML profile for OWL, we propose an extension to UML class diagrams (hard extension) that allows a more compact OWL visualization. The compactness is achieved through the native power of UML class diagrams extended with optional Manchester encoding for class expressions thus avoiding many explicit anonymous classes typical in ODM. We have implemented the proposed compact visualization in a UML style graphical editor for OWL 2. The editor contains a rich set of graphical layout algorithms for automatic ontology visualization, search facilities, graphical refactoring and interoperability with Protégé 4.
Conference Paper
Full-text available
Although the Internet, as an ubiquitous medium for communication, publication and research, already significantly influenced the way historians work, the capabilities of the Web as a direct medium for collaboration in historic research are not much explored. We report about the application of an adaptive, semantics-based knowledge engineering approach for the development of a prosopographical knowledge base on the Web - the Catalogus Professorum Lipsiensis. In order to enable historians to collect, structure and publish prosopographical knowledge an ontology was developed and knowledge engineering facilities based on the semantic data wiki OntoWiki were implemented. The resulting knowledge base contains information about more than 14.000 entities and is tightly interlinked with the emerging Web of Data. For access and exploration by other historians a number of access interfaces were developed, such as a visual SPARQL query builder, a relationship finder and a Linked Data interface. The approach is transferable to other prosopographical research projects and historical research in general, thus improving the collaboration in historic research communities and facilitating the reusability of historic research results.
Conference Paper
Full-text available
In many data-centric applications, we would like to use OWL to express constraints that must be satisfied by instance data. However, the Open World Assumption (OWA) in OWL’s standard semantics, combined with the absence of the Unique Name Assumption (UNA), makes it difficult to use OWL in this way. What triggers constraint violations in closed world systems leads to new inferences in standard OWL systems. In this paper, we present an Integrity Constraint (IC) semantics for OWL axioms that is based on Closed World Assumption (CWA) and weak UNA to address this issue. Ontology modelers can choose which axioms will be interpreted with IC semantics, thus combine open world reasoning with closed world constraint validation in a flexible way. We also show that IC validation can be reduced to query answering under certain conditions. Finally, we briefly describe our prototype implementation based on the OWL reasoner Pellet. 1.