use when formulating queries for the subsystems. The
Shared Ontology (SO) is therefore the union of all the
upper OFs plus all the relations and concepts that are
specific to the JUMP system; since some concepts are
repeated across systems, the creation of the SO is the
point in which alignment techniques have to be used
in order to simplify and generalize the query writing
phase of the search.
The JUMP component has therefore to interface
with a generic service, sketched in Figure 2, knowing
which subset of concepts and relations are understood
by the service, and has to query it in order to discover
which items that could be relevant for the user the ser-
vice can return.
Figure 2: Sketch of a subsystem architecture.
2.3 Communication Protocols
Being each service based on an existing system that
can potentially use any technology or programming
paradigm, our design choice was to model services
as Web Services or HTTP services, depending on the
specific necessity. More in detail, we identified two
possible requests to a service:
• Find all relevant metadata for a request, i.e. an-
swer a SPARQL query, using the system specific
ontology where possible in order to refine the
query
• Return a specified item upon request (items can
be binary objects in any format)
The first request, in practice, can be answered
through the implementation of the SPARQL Pro-
tocol
4
(which amounts to the ability to answer a
SPARQL query through an HTTP or SOAP request),
while the second request can be easily filfilled through
the use of a simple HTTP service, that will answer
to a GET operation with suitable arguments; the rea-
son to use HTTP instead of a Web Service interface is
that, as already said, the items to be presented can be
4
http://www.w3.org/TR/rdf-sparql-query/
generic textual or binary objects, in some cases quite
large in size (w.r.t the E-Learning system, the size of
a resource, say a video tutorial for example, can reach
hundreds of megabytes), and therefore the additional
overload of SOAP serialization can be a serious per-
formance bottleneck, not providing any actual advan-
tage over the HTTP solution.
The internal architecture of an ancillary system is
responsibility of the single developer; however, the
JUMP project aims at integrating the four abovemen-
tioned systems in the platform proposing and sharing
a common architectural design. This architecture is
sketched in Figure 2.
The RDFCore component represented in the sub-
system architecture is a RDF storage system built on
top of the Jena Toolkit; it offers a SPARQL Protocol
implementation that, depending on the specific sub-
system architecture, can be directly used to imple-
ment the subsystem interface to the JUMP framework
or can be used to simplify data access. The solution
is described in more detail in (Stoermer et al., 2006).
2.4 Dataflow Design Metaphor
The architecture described here is based on the
metaphor of data pipes: by reusing an idea presented
in (Palmisano et al., 2006), we model the answer to
the input query as a data flow coming out of the con-
junction of many data streams, each one originating
into a Store and corresponding to a URI in the query
Dataset. Since it is possible that different parts of
the query refer to different portions of the knowledge
base (i.e. some variables of the SPARQL query can
be fully binded in a subset of the dataset), we wrap
the query execution in a component called Query An-
alyzer, which has responsibility to split or rewrite the
query through the different portions of the knowledge
base, which are then queried independently.
The knowledge necessary to redirect a pattern to
a specific portion of the dataset must be available for
the Query Analyzer component, in order to rewrite
the query for each specific Locator that will feed the
results. This information can be represented as a list
of URIs associated to each section of the knowledge
base, where each URI corresponds to one of the pred-
icates of the statements contained in that section of
the knowledge base, or to the types of the individu-
als described therein; moreover, it is possible to do
the same thing with a set of namespaces instead of
full URIs, but this implies that different namespaces
are to be used for different sections of the knowledge
base; to prevent clashing, it is possible to just think
of joining two pipes with the same set of namespaces
or URIs (or where one has a superset of the other),
ICEIS 2007 - International Conference on Enterprise Information Systems
430