SemSon

Connecting Ontologies and Web Applications

Geert Vanderhulst, Kris Luyten and Karin Coninx

Hasselt-University – transnationale Universiteit Limburg

Expertise Centre for Digital Media, Wetenschapspark 2, 3590 Diepenbeek, Belgium

Keywords:

Semantic web, Web-based applications, Ontologies.

Abstract:

The emerge of semantic data on the web puts the development of dynamic web applications to the test. On the

one hand, we witness more and more semantic information becoming available on the web. On the other hand,

we can see web-based applications evolve from server-side applications to responsive client-side applications

running in a web browser. In this paper we present a framework that bridges the gap between semantic data

deﬁned in OWL ontologies and client-side web applications implemented in JavaScript.

1 INTRODUCTION

The shift to dynamic Web applications running in a

Web browser has brought up the need to interact with

remote data from client-side scripts. At the same time,

an increasing amount of meaningful information is

published on the Web, making it possible for Web

applications to better understand and satisfy requests

between users and machines as envisioned by the se-

mantic Web (Berners-Lee et al., 2001). Since most

Web-based applications still rely on a ﬁxed database

schema, the semantics of the application data are of-

ten known in advance and interaction with a Web

server’s database can be abstracted using data objects.

However, when developers start to adopt ontologies as

a means to structure, query and share information, the

full semantics of available data are not always known

beforehand. For example, one ontology can extend

another ontology with extra concepts and relations

and hence give rise to a richer knowledge base. In

this case, data objects should adapt to match the con-

cepts in the aggregated knowledge base, in order to

fully exploit the available information.

In this paper we present a framework, called Sem-

Son, that dynamically maps information deﬁned in an

ontology on scripted data objects and vice versa. Even

though there are fundamental differences between

object-oriented programming (OOP) languages and

knowledge representation frameworks such as OWL

(Koide and Takeda, 2006), we show that a dynamic

programming language such as JavaScript (JS) is very

suitable for semantic data binding using OOP. We use

SPARQL (Prud’hommeaux and Seaborne, 2008) and

JSON

as glue to connect semantic data and JS ob-

jects on the ﬂy. SemSon contributes to an improved

scalability of Web applications that leverage seman-

tic data by providing constructs to 1) map OWL in-

stances on JS objects and 2) create new JS objects

that adhere to an OWL class deﬁnition.

2 RELATED WORK

In (Koide and Takeda, 2006), the semantic gap be-

tween OOP languages and OWL is explained: vari-

ous discrepancies between static OOP languages such

as Java and OWL/RDF are due to a mismatch be-

tween OWL classes/individuals and OOP classes/in-

stances. The authors show that these mismatches can

be addressed by using a more dynamic and reﬂective

OOP language such as Common Lisp Object System

(CLOS) and present an OWL processor built on top

of CLOS that allows programmers to develop appli-

cation domain models using OOP. A more static ap-

proach for mapping an OWL ontology on Java classes

and instances is presented in (Kalyanpur et al., 2004).

In this work a solution is proposed to create a set

of Java interfaces and classes from an OWL ontol-

ogy whilst minimizing the impact of fundamental se-

mantic differences. An instance of a Java class repre-

sents an instance of a single class of the ontology with

most of its properties, class relationships and restric-

http://json.org/

163

Vanderhulst G., Luyten K. and Coninx K.

SemSon - Connecting Ontologies and Web Applications.

DOI: 10.5220/0002770201630166

In Proceedings of the 6th International Conference on Web Information Systems and Technology (WEBIST 2010), page

ISBN: 978-989-674-025-2

tion deﬁnitions maintained.

Our work focuses on the dynamic use of OWL

constructs in JS to make meaningful information

directly available to client-side Web applications.

JavaScript, the default programming language to de-

velop this type of applications, is just like CLOS very

ﬂexible in the way objects are composed: objects can

be redeﬁned and extended with new properties and

methods at runtime. A growing interest of JSON in

combination with semantic Web technologies such as

SPARQL also motivates our research. For instance,

SPARQL query results can be serialized into JSON

and thus processed efﬁciently in JS using OOP (Clark

et al., 2007).

3 OWL NOTATION IN JSON

Ontology experts think in terms of concepts and re-

lations while many software developers think object-

oriented. We connect both worlds by representing in-

formation deﬁned in an OWL ontology using class

objects and individual objects, expressed in JSON.

Class and individual objects correspond to OWL class

and individual descriptions respectively as depicted in

ﬁgure 1. In both representations, URIs (namespaces

and identiﬁers) are used to refer to objects (JSON)

and resources (OWL). Note however that SemSon is

not an API for OWL, but rather provides a means to

generate JS objects from OWL DL semantics. We

rely on the DL subset of the complete OWL vocabu-

lary because it enforces a strict separation of classes,

properties, individuals and data values which is also

found in OOP languages.

Figure 1: Mapping OWL to JSON.

In the remainder of this section we give a brief

overview of the representation of OWL class descrip-

tions in JSON and section 4 elaborates on the cre-

ation, use and validation of individual objects.

Class Descriptions. OWL classes can be described

using a simple class identiﬁer (URI reference) or built

using the following constructs for which we provide

a JSON equivalent:

• Enumeration: an OWL class can be described by

exhaustively enumerating its individuals.

{” owl ” : {” oneOf ” : [ ”A” , ”B” ] } }

• Intersection, union, complement: AND, OR and

NOT operators can be applied to OWL class de-

scriptions.

{” owl ” : {” i n t e r s e c t i o n O f ” : [”A” , ”B” ] } }

{” owl ” : { ” comp leme ntOf ” : ” A”}}

• Properties: properties are linked with class de-

scriptions through domain and range axioms. Re-

strictions on properties put additional constraints

on the range of an OWL property when applied to

a particular class description (value constraints) or

on the number of values a property can take (car-

dinality constraints).

{” owl ” : {” p r o p e r t i e s ” : [ { ” u r i ” : ”P ” ,

” r an g e ” : [ ” A” ,B” ] , ” c a r d i n a l i t y ” :

” 1 ”} , {” u r i ” : ”Q” , ” h a sV a l ue ” : [ ”C” ] } ] } }

Class Axioms. OWL contains three language con-

structs for combining class descriptions into class ax-

ioms. These axioms describe inheritance, equivalence

and disjointness relations that exist between classes.

{” owl ” : {” su b C l as s Of ” : [ ”A” ] } ,

{” e q u i v a l e n t C l a s s ” : [ ” B” ] } ,

{” d i s j o i n t W i t h ” : [ ” C ” ] }}

This information enables a developer to reason

about the class hierarchy and semantically compare

classes.

4 SEMSON FRAMEWORK

The SemSon framework consists of a JavaScript li-

brary (semson.js) and a collection of Java-based

servlets (semson.war) which connect scripts running

in a Web browser with ontologies published on the

Web, as shown in ﬁgure 2. We use Jena

as seman-

tic data store (DS), Pellet (Sirin et al., 2007) as rea-

soner and SPARQL as query language. Table 1 lists

the main operations supported by SemSon.

4.1 Import and Query Ontologies

Data is made available to Web applications through a

semantic DS which acts as an application’s database.

Instead of using a ﬁxed database schema, SemSon al-

lows programmers to specify the ontologies they want

to use at runtime and dynamically loads them into a

semantic DS. Once in the DS, information from the

ontology can be derived by constructing JS objects

that correspond to a class or individual whose related

data is transparently retrieved from the DS or by us-

ing SPARQL queries when more speciﬁc semantic

http://jena.sourceforge.net/

WEBIST 2010 - 6th International Conference on Web Information Systems and Technologies

164

data selection is needed. A preprocessing step gen-

erates native JS object wrappers for each OWL class

description in an ontology. These wrappers support

the creation of objects in OOP-style: new myclass()

is equivalent with semson.i(’myclass’). When prepro-

cessing is omitted,e.g. when dealing with large on-

tologies with many class descriptions, class objects

are resolved on an as-needed basis.

Figure 2: SemSon architecture.

Table 1: Main SemSon operations.

import(location)

Import an ontology into a se-

mantic DS.

c(c_uri)

Create a class object from an

OWL class description.

i(c_uri,i_uri)

Generate an individual object

from an OWL class description.

validate(i,c)

Validate an individual object

against a class object.

update()

Receive class or individual data

from a semantic DS.

commit()

Send individual data to a se-

mantic DS.

4.2 Create Individual Objects

In SemSon, objects are automatically generated from

an OWL class description at runtime. Software devel-

opers only need a minimal understanding of the on-

tologies designed by domain experts such as available

classes and their properties. Objects abstract underly-

ing (instances of) ontologies and thus simplify work-

ing with semantic data. Furthermore, when an ontol-

ogy is modiﬁed, data objects are updated accordingly:

the application developer gets an updated data inter-

face for free. Consider for instance an object that rep-

resents a person described in an ontology with names-

pace ns. This object is created as follows:

v a r p = new ns . P e rso n ( ) ;

/ / eq . semson . i ( ’ ns : P er so n ’ ) ;

To construct an instance of a class, we analyze the

class description fetched from the ontology as de-

scribed in section 3 and dynamically generate an ob-

ject whose member variables match the OWL proper-

ties and their restrictions. For example, if a restriction

on the ns:Person class deﬁnes that a person has zero

or more hobbies, we generate a hobbies member vari-

able that corresponds to an array:

p . f i r s t N a m e = ’ John ’ ;

p . h o b b i e s . pu sh ( ’ Swimming ’ ) ;

Moreover, we have to take into account class descrip-

tions based on intersection, union and complement as

well as axioms such as rdfs:subClassOf when generat-

ing objects. These constructs specify the individuals

that are supported by a class and thus also indicate

valid properties for instances of classes. We select

a superset of properties which allow to create valid

class instances and map these on object member vari-

ables. Whether an instance is compliant to a class

or not can be validated at runtime (see further). To

avoid clashes with member variables, we use names-

paces to differentiate between similar properties, e.g.

obj.property versus obj.ns.property.

4.3 Validate Individual Objects

Most restrictions on properties and classes are hard

to enforce while generating an individual object. An

individual object can be manipulated at runtime and

become incompatible with its class object. To detect

inconsistencies, SemSon includes a validation algo-

rithm implemented in JavaScript – validate(i,c), with i

an individual object and c a class object – which com-

pares the data of an individual object with its corre-

sponding class object. The algorithm currently con-

sists of three steps:

1. Enumeration Checking: check whether i equals

one of the allowed individuals for c.

2. Property Checking: verify whether properties de-

clared in an object are allowed, have valid values

and a correct number of elements. This also in-

volves class and datatype checking, for instance

to assert that a property value indeed matches a

class or value within a speciﬁed range.

3. Intersection, Union, Complement Checking: as-

sert that an object passes the following tests:

validate(this,A) && validate(this,B),

validate(this,A) || validate(this,B),

!validate(this,A)

The validation algorithm runs in a Web browser

and is fast, but it does not carry out advanced rea-

soning techniques or complex datatype checking (e.g.

user deﬁned schema types). Its main purpose is to

provide an efﬁcient means to debug client-side Web

applications by asserting that data objects are valid

at strategic places in the program. Besides, the algo-

rithm can be used to quickly validate user input by

encapsulating input data in an individual object and

SemSon - Connecting Ontologies and Web Applications

165

performing validation. However, to make sure a se-

mantic DS remains consistent, a more powerful ap-

proach towards consistency checking is needed. This

is achieved by installing an OWL reasoner such as

Pellet (Sirin et al., 2007) between query engine and

DS which analyzes data before making it persistent.

4.4 Semantic Data Binding

A class or individual object is ﬁlled with data from the

DS by invoking its update function and data is sent

back to the DS by executing the commit function. For

performance reasons, we implemented these methods

in SemSon servlets deployed on a Web server which

have direct access to the DS. An update extracts data

from the DS using the resource’s URI as a reference

and maps this information on JSON as depicted in

ﬁgure 1. At the client-side script, the JSON data

is converted into an object and convenience methods

are added. A commit sends an object serialized into

JSON to the Web server where it is checked by a rea-

soner for consistency and ﬁnally added to the DS. We

also support an atomic commit operation in SemSon

using transactions. In a transaction, multiple individ-

ual objects can be grouped together and committed to

the DS in a single operation.

5 DISCUSSION AND

CONCLUSIONS

As a proof of concept, we have developed a prototype

Web application in which we use an OWL DL version

of the Friend of a Friend (FOAF) vocabulary to create

user proﬁles (see listing 1). The FOAF ontology

is imported into the DS and is preprocessed so that

OWL classes and individuals can be directly instanti-

ated using OOP. In this example, we use a transaction

to send the new and updated user proﬁle to the DS

and verify the information was stored correctly using

a SPARQL query. When the ontology is extended

with constraints on properties which e.g. state that

each person must have a valid name, we can validate

individual objects at runtime. Furthermore, the Pellet

reasoner can be used to automatically infer missing

information when adding data to a DS. For example,

if FOAF is extended with family relations which

typically include inverse relations such as A parentOf

B ⇔ B childOf A, the reasoner can automatically

infer missing facts and add them to the DS to keep

ontologies and their instances consistent at all times.

We have presented a framework

for developing

http://research.edm.uhasselt.be/semson/

dynamic Web applications that can create and/or use

semantic data from within a Web browser. SemSon is

targeted toward programmers who are familiar with

JavaScript, but only have a basic understanding of

OWL and ontologies in general. Besides the FOAF

example, we have used SemSon to create a Web

interface for controlling a pervasive environment

described using different domain-speciﬁc ontologies.

For now, the DS is disadvantageous for the scalability

of our approach since it is a centralized component.

When facing large data sets (and associated complex

ontologies) it needs to be replaced by a distributed

storage and querying solution.

v a r f o a f n s =

’ h t t p : / / www. mindswap . o r g / 2 0 0 3 / owl / f o a f ’ ;

v a r f r i e n d = ’ h t t p : / / myns / m y f r iend ’ ;

semson . r e g i s t e r N S ( ’ f o a f ’ , f o a f n s ) ;

semson . i m p o r t ( f o a f n s , t r u e ) ;

/ / r e g i s t e r c l a s s o b j e c t s

v a r p1 = new f o a f . P e rs o n ( ) ;

/ / c r e a t e i n d i v i d u a l s

p1 . f i r s t N a m e = ’ f i r s t ’ ; p1 . s urname = ’ l a s t ’ ;

v a r p2 = new f o a f . P e rs o n ( f r i e n d ) ;

p1 . knows . push ( p2 . u r i ) ;

p2 . knows . push ( p1 . u r i ) ;

semson . commit ( p1 , p2 ) ; / / t r a n s a c t i o n

v a r q = ’SELECT ? p

WHERE {? p f o a f : knows <’+ f r i e n d + ’ > } ’;

v a r q r = semson . s e l e c t ( q ) ; / / q u e r y i n g

f o r ( b i n q r . r e s u l t s . b i n d i n g s )

i f ( q r . r e s u l t s . b i n d i n g s [ b ] . p . v a l u e

== p1 . u r i )

a l e r t ( ’ f o u n d ! ’ ) ;

Listing 1: Creating a FOAF user proﬁle using SemSon.

REFERENCES

Berners-Lee, T., Hendler, J., and Lassila, O. (2001). The

Semantic Web. Scientiﬁc American, pages 34–43.

Clark, K. G., Feigenbaum, L., and Torres, E. (2007).

Serializing SPARQL Query Results in JSON.

http://www.w3.org/TR/rdf-sparql-json-res/.

Kalyanpur, A., Pastor, D. J., Battle, S., and Padget, J. A.

(2004). Automatic Mapping of OWL Ontologies into

Java. In SEKE’04, pages 98–103.

Koide, S. and Takeda, H. (2006). OWL-Full Reasoning

from an Object Oriented Perspective. In ASWC’06,

pages 263–277.

Prud’hommeaux, E. and Seaborne, A. (2008). SPARQL

Query Language for RDF. http://www.w3.org/TR/rdf-

sparql-query/.

Sirin, E., Parsia, B., Grau, B., Kalyanpur, A., and Katz, Y.

(2007). Pellet: A practical OWL-DL reasoner. Web

Semantics: Science, Services and Agents on the World

Wide Web, 5(2):51–53.

WEBIST 2010 - 6th International Conference on Web Information Systems and Technologies

166