Content uploaded by Martins Zviedris
Author content
All content in this area was uploaded by Martins Zviedris on Oct 25, 2015
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
Java Annotation
OWL XML tag
JAVA element
RdfOntClass
owl:Class
class
RdfDataTypeProperty
owl:DatatypeProperty
class internal variable with
primitive data type (String,
Integer, etc.)
RdfObjectProperty
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) OntoViews—a tool for cre-
ating semantic web portals. In: Proceedings of 3rd International Semantic Web
Conference (ISWC 2004), Hiroshima, Japan, Springer–Verlag
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):377–90.
