SeWeSe : Semantic Web Server

All semantic web applications using a semantic engine rely on common functionalities that can be factorized into a semantic web application development platform.

That is the purpose of SeWeSe.

acacia Fabien GANDON, Fabien.Gandon@sophia.inria.fr
Priscille Durville, Priscille.Durville@sophia.inria.fr

Introduction: from Corese to Sewese

Our team uses and maintains a SPARQL search engine named "Corese"

A large number of the applications we develop are webapps.
Semantic web applications using a semantic engine rely on common functionalities (e.g. load, query, run rules).
This functionalities can be factorized into a development platform.
Sewese is designed to...
- reduce the amount of time spent to develop new semantic web applications.
- to allow these applications to focus on their domain specificities.

Architecture overview

Dependencies

Sewese is a Java 5 application and hasto be embedded in webapps deployed on a servlet container

It can be deployed under Tomcat 5.5.x and uses Servlet API 2.4, JSP 2.0 and the standard JSP Tag library 1.1.2.

It uses the following opensource libraries:

XSLT engine Xalan 2.7.0
the logging library Log4J 1.2.12
the workflow library of Opensymphony (OSWokflow 2.8.0)
the file upload library of Apache (commons-fileupload 1.1.1)
javax.mail 1.4 and javax activation 1.1

XML technologies for every non-java files (e.g JSPX, XSL, XML).

Relying as much as possible

on RDF/S to represent our data (user profile, logs, etc.)
so data can be integrated wherever they come from
on SPARQL to select them (session parameters, history, access rules, etc.)
so interactions with the server are always done the same way

Sewese components

Sewese provides a set of filters, servlets, JSP tags and libraries as well as some templates to build new applications ; it is organized around four main types of components:

Toolkits:

group back-end interfaces (e.g. accesses to Corese) and transversal functionalities (e.g. applying an XSLT stylesheet)
documented API and one instance of each toolkit placed in the context
developers can reuse them directly
recurrent calls or shared resources can be factorized and cached

Filters: provide mechanisms to implement transversal processing on requests and response
e.g. maintain context variable about the user's profile using parameterized SPARQL queries

JSP Lib: (Semtags)

Servlets: implement responses requiring important processing
e.g. a servlet implements the update of a class in an existing ontology

Toolkits

EngineToolkit to submit SPARQL queries to the semantic search engine,
OntologyToolkit to manage the ontologies,
NotionToolkit to handle objects representing RDFS classes and properties,
AnnotationToolkit to manage RDF annotations,
NotifyToolkit to allow users to monitor targeted events,
SemanticLoggerToolkit to log custom events as RDF annotations
DistanceToolkit to calculate semantic distance between two notions,
SessionManagerToolkit to manage users' profile as RDF annotations,
XSLTToolkit to apply efficiently XSLT stylesheets (caching mechanisms),
DOMToolkit to manipulate elements of an XML document,
ConcurrentToolkit provides functionalities to handle concurrent accesses to the resources of the application,
WorkflowToolkit to automate some processes based on declarative descriptions ; based on OSWokflow to implement document flows in XML,

JSP Tags Lib (Semtags)

tags to display and navigate in all or sub-parts of RDFS schemas
tags to create new annotations in the knowledge base
tags to modify existing annotations
tags to include the result of a query and specify the stylesheet to format it or directly manipulate the binding in JSP,
administration tags (e.g. to reset the server)
tags to lock resources to manage concurrency
tags to provide graphic widgets (e.g. calendar to select a date, dialog pop-ups, tooltips)
tags to handle security and access control.

Filters

The session filter provides standard session management functionalities plus a declarative way to handle the data about a user
The access filters allow setting restrictions on access rights for targeted resources ; access constraints are expressed in SPARQL using the ASK clause.
tags to include the result of a query and specify the stylesheet to format it or directly manipulate the binding in JSP,
Dynamic generation of resources using JSP templates (e.g. parameterize a CSS stylesheet)
The template filter provides a simple way to apply a template to a set of pages ; it can rely on SPARQL too.

Some visual examples.

screenshots of some webapps using Sewese.

Pie chart view for a result

Figure 2 : Example of a customized annotations view (pie chart view)

Results shown as a table

Figure 3 : Example of a query results view (shown as table)

Bar chart view

Interactive radar view

Customized query graphical interface

Customized query results

Interface for annotations modification

Semtags JSP Lib.

Examples of tags from the JSP library released last week and ready to be used for lightweight applications.

Initialize and query

The first thing to do is to initialize at least one Corese instance to load annotations and ontologies.

00 01 02 03 04 05

<c:if test="${empty applicationScope['defaultEngineWrapper']}"> <stl:init ontoDir="WEB-INF/data/schemas" annotDir="WEB-INF/data/annotations" ruleDir="WEB-INF/data/rules" humans="http://www.inria.fr/2007/04/17/humans.rdfs#" /> </c:if>

Several tags to run SPARQL queries but most useful one is a JSP loop tag to directly iterate over the results

01 02 03 04 05

Query (II)

There is also a function to quickly send a query and obtain the first value of the first result:

01 02 03

<c:set var="myQuery" value="SELECT ?age WHERE { ?x humans:name 'John' . ?x humans:age ?age }" /> John is ${stl:quickQuery(pageContext,myQuery)}-year old.

Equivalents of the classical if and choose tags but using SPARQL queries as test.

01 02 03 04 05 06 07 08 09 10 11 12

<stl:for-each-result query="SELECT ?x ?name ?age WHERE { ?x humans:name ?name . OPTIONAL { ?x humans:age ?age } }"> <li> <stl:choose> <stl:when test="ASK { <${x}> rdf:type humans:Female }"> <span style="color: red">${name}</span></stl:when> <stl:when test="ASK { <${x}> rdf:type humans:Male }"> <span style="color: blue">${name}</span></stl:when> <stl:otherwise>${name}</stl:otherwise> </stl:choose> <c:if test="${!empty age}"> (${age})</c:if> </li> </stl:for-each-result>

Query schemas

There are functions to access the schemas.

01 02 03 04 05 06 07

<ul> <stl:for-each-child root="http://www.inria.fr/2007/04/17/humans.rdfs#Animal" var="current"> <li>${stl:label(pageContext, current, 'en', true)} (${stl:allInstanceNb(pageContext, current)})</li> </stl:for-each-child> </ul>

Identify the roots.

01 02 03 04 05

<ul> <stl:for-each-root-concept var="current"> <li>${stl:label(pageContext, current, 'en', true)}</li> </stl:for-each-root-concept> </ul>

Edit RDF files

Tags to modify RDF/XML files.

01 02 03 04 05 06 07 08 09 10

<stl:modify-annot kind="replace" xpath="/rdf:RDF/humans:Person/humans:name[text()='${param['name_before']}']" forceUpdate="true" file="human_2007_04_17.rdf" humans="http://www.inria.fr/2007/04/17/humans.rdfs#" rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <humans:name xmlns:humans="http://www.inria.fr/2007/04/17/humans.rdfs#"> ${param['name_after']} </humans:name> </stl:modify-annot>

Many other tags ; see online API doc.

Including also Corese goodies such as...

rule engine
grouping
sorting
sum, average, etc.
validation
approximate query...

Approximate query in Corese

My watch has one hand... but it's not a bug... it's a feature!

In IR precision and logical truth are not always the main criteria.

Sometime we just want a result "good enough".
Sometime a close enough answer is better than nothing.

Corese allows us to relax typing constraints (e.g. "handout" vs. "tutorial") using the length of the paths between types to evaluate the "cost" of the approximation.

Approximate query in Swese

Query with approximation.