The open source project Edutella is a Peer-to-Peer (P2P) network for learning materials. It builds upon meta data standards defined for the WWW and aims to provide a RDF-based meta data infrastructure for P2P applications. In this paper we discuss a prototype provider peer for the Edutella network, which provides advanced reasoning peers for RDF data. This prototype peer provides storage and querying services for which it uses the ConceptBase database with its powerful reasoning mechanism as storage and query facility. ConceptBase implements the meta data language O-Telos while Edutella uses RDF(S). Based on previous work in this area we present a mechanism to translate the property-centered meta modeling language RDF to the object-centered meta modeling language O-Telos. Thus we are able to provide a Datalog based reasoning facility for the P2P Edutella network. As the Edutella network also uses the query exchange language RDF-QEL we also describe in detail the peer's query service. It translates RDF-QEL queries to O-Telos queries and the respective O-Telos answers to RDF-QEL answers.
Within the last year we have been working on a project towards
implementing an extendable open source meta data-based
peer-topeer infrastructure called Edutella for the exchange of distributed
resources. Resources initially considered are learning materials but
the infrastructure is agnostic to the specific type of resources to be
exchanged. In our case we have large collections of learning
material and we are working on annotating this material with RDF [
In its current state the Edutella network consists of client- and
provider-peers. A client-peer poses queries to the Edutella network
and displays the answers returned from the network. The
providerpeers receive the queries from the network and answer them if
possible. Thus a peer must realize a storage and query service for the
Edutella network in order to function as a provider-peer. For a
complete description of Edutella see the Edutella White Paper [
In this paper we describe a provider-peer and its services for
the Edutella network, which provides extended reasoning
capabilities. The provider-peer uses the ConceptBase database [
The provider-peer provides two basic services which we will
present in this paper. On one hand it is designed to store RDF(S) data
in the ConceptBase repository; the storage service. The data
represented in RDF(S) is translated to O-Telos which is used by the
repository. The translation uses the RDF-O-Telos axioms as described in
[
On the other hand the provider-peer serves as a query interface to
the RDF data stored in the ConceptBase repository; the query
service. Queries formulated in the RDF exchange language RDF-QEL
[
Combining the storage and query service with ConceptBases’ Datalog reasoning facilities enables us to reason about the meta data used in the Edutella network.
This paper is structured as follows: the next chapter describes how RDF(s) data is stored in ConceptBase. With the help of a simple example our translation algorithm is explained in more detail. The third chapter deals with the querying facility provided by this peer. We explain how we are able to use the advanced querying facilities of ConceptBase for querying RDF(S) data. The fourth chapter describes briefly the technical issues concerned with this provider peer. A short summary closes the paper. 2
The resources exchanged in the Edutella network are basically
learning materials, each learning object is described by RDF(S) data. In
this paper we describe a way to provide an Edutella peer to store and
retrieve RDF(S) data. The example used throughout this paper is a
small database containing the RDF description of some books. This
database is taken from the Edutella [
In order to store the RDF meta data in the ConceptBase database
the peer has to translate RDF to O-Telos. O-Telos itself is an
objectoriented modeling language defined by 32 axioms. In order to
translate RDF to O-Telos it is necessary to modify and eventually extend
RDF(S). Therefore we have developed a translation based on the
axioms from O-Telos-RDF. For a description of O-Telos-RDF and its
defining axioms please see [
The algorithm ensures that RDF(S) data is translated without any loss of information. At first we are changing the representation from XML serialization to its representation as triple statements. Each triple is provided with an unique id. Furthermore the quadruples built are eventually supplemented with additional quadruples capturing further facts of the actual namespace to fulfill the axioms of O-Telos and O-Telos-RDF. The sum of compound and generated quadruples form the O-Telos database where each quadruple represents an OTelos statement.
An O-Telos quadruple statement has the form (sid,subject,literal,object). Sid, subject and object are unique statement identifiers. Sid identifies the statement that connects the subject statement with the object statement using the predicate literal. Sid and subject can hold the same identifier only if sid, subject and object are the same identifier, so that the statement represents an individual with the literal as name. O-Telos declares several predefined literals like the In literal stating instantiation, the IsA literal stating inheritance, etc.
As an example for the translation process we will focus on just one RDF resource description. The translation of the other resource descriptions of the example book database follows basically the same procedure varying in small details only. The RDF statements for the example resource http://www.xyz.com/jv.html describe a book with its properties “Just Java” of type dc:title and “Peter van der Linden” of type dc:author. The resource itself is of the rdf:type http://www.lit.edu/ types#Book.
The RDF-triple representation of this resource description is given in table 1.
Nr. 1 2 3
The O-Telos quadruples that describe the example resource http://www.xyz.com/jv.html are given in table 2. Statement #1 represents a individual name http www xyz com jv html. This individual is instance of a class #Book and a class #DCElements11 (statements #2 and #3). The individual has an attribute named title1 connecting it to the object ”Just Java”. The attribute is instance of #DCElements11.title. The individual is also connected to the object ”Peter van der Linden” with the author1 attribute. This attribute is instance of #DCElements11.author. Also the individual is connected via the namespace1 attribute to ”http://www.xyz.com/” which is an instance of #Book.namespace.
The translation from RDF triple to O-Telos quadruple representation employ the axioms from O-Telos-RDF. Especially the axioms describing instantiation, property and type translation are used. Note that each RDF statement obtains a unique id to form the O-Telos statement. The ids are the statement identifiers really and as such are unique globally (except when exactly the same statements are made in two different places. In our example the ids are represented by a short form sidx to enhance readability which would expand to namespace:resourcename, e.g. here sid1 is the abbreviated form for http://www.xyz.com:jv.html.
If a RDF statement includes elements from other than the current schema, identified by a different than the current namespace, these elements are grouped in specially created O-Telos classes. For example the properties of the “Just Java” books’ RDF description dc:title and dc:author, originating in the Dublin Core schema, are grouped in an O-Telos class called DCElements11 (see table 2). Note that the sids prefixed with ’#’ are stated for simplicity reasons and denote the respective class names. In reality these are again statements with own ids which would enlarge the example without adding any new insight. We therefore use the shortcut with the ’#’ prefix and the class name instead.
Also the O-Telos attribute namespace is introduced to hold the namespace of each RDF resource and property. Usually the namespace is part of the unique id of each statement as hinted in the example 2.1 but unfortunately the O-Telos frame syntax and parser forbids the possible special characters like dot, slash, dash, backslash, etc. of URLs in the element name. Therefore we introduce the namespace attribute that is assigned to each element and attribute. This attribute holds the namespace or resource URL respectively as a work around. Individual http___www_xyz_com_jv_html in Book, DCElements with title
title1 : "Just Java" author
author1 : "Peter van der Linden" attribute
namespace : "http://www.xyz.com/" end Example 2.1: O-Telos frame representation of the book ”Just Java”
The frame representation of the O-Telos quadruples of table 2 is stated in example 2.1.
From the small example of the book ”Just Java” in its RDF and O-Telos descriptions we have gained an insight on the translation of RDF to O-Telos. When applied to the whole book database the respective complete O-Telos representation is generated and stored in the ConceptBase database. Thus figure 2 shows the O-Telos graph of the same part of the book database which is shown as RDF graph in figure 1
The comparison of both graphs of the book database (figure 1 for RDF and figure 2 for O-Telos) shows their equivalence. They are different representations of the same book database using various different notations and serializations (triple/quadruple and XML/frame syntax). Thus by employing the translation described above it is possible to store RDF(S) data in the O-Telos meta data language. The next chapter shows how the lossless transformation of the RDF(S) data from its O-Telos representation is realized. 3
The chapter will provide some insight in how the data stored in an
OTelos provider-peer is regained using RDF queries. The RDF queries
are posed to the peer by using the RDF-QEL exchange language as
described in [
RDF-QEL does not distinguish between data and schema levels
thus enabling the querying of different modeling levels. In doing
so RDF-QEL conforms with the RDF(S) schema definitions and
the more recent RDF model theory [
The RDF-QEL queries are translated into O-Telos queries which than are posed to and answered by the ConceptBase database. The O-Telos answers are translated back to RDF in XML serialization. In order to clarify the translation further we will stick with the example from above. There the RDF description of the resource with the URL http://www.xyz.com/jv.html and the title “Just Java” is stored in the database. <?xml version=’1.0’ encoding=’ISO-8859-1’?> <!DOCTYPE rdf:RDF [ <!ENTITY rdf ’http://www.w3.org/1999/02 /22-rdf-syntax-ns#’> <!ENTITY rdfs ’http://www.w3.org/2000/0 1/rdf-schema#’> <!ENTITY dc ’http://purl.org/dc/element s/1.1/’> <!ENTITY edu ’http://www.edutella.org/e dutella#’>
Now we want to know from the book database which books have the title “Just Java”. The respective query expressed in RDF-QEL-1 and XML is stated in example 3.1.
The query asks for at least one resource in the database which has a property called dc:title with a value “Just Java”. The resulting resource(s) are returned in XML notation. The peer constructs from this RDF representation the respective O-Telos representation. Thus the query is reformulated in O-Telos so that it now states that there is at least one resource in the database which has a property called dc:title with a value “Just Java”. If this is true the respective resources are retrieved.
As the example in 3.2 shows is each query an instance of ConceptBase’s build-in class QueryClass. It is a subclass of the O-Telos class Individual thus has as answers other instances of the class Individual. The answers hold attributes called title and namespace of type String. The constraint varX declares that all instances of the answer set must have an attribute named title and that this attribute holds the value ”Just Java”.
The namespace of the title attribute is derived from ConceptBase with a second query. For simplicity reasons we omit this query here. The query answers are than translated to RDF as shown in example 3.4.
QueryClass EduQuery isA Individual with retrieved_attribute title : String; namespace : String constraint varX : $ exists Y/Individual
A(this,title,Y) and A(this,title,"Just Java") $ end end Example 3.2: The O-Telos frame representation of the query example jv_html in EduQuery with title
tit1 : "Just Java" namespace
nam1 : "http://www.xyz.com/" Example 3.3: Frame syntax of ConceptBases’ answer for the query shown in 3.2
The answer consists of RDF statements declaring that there is a resource with URL http://www.xyz.com/jv.html. This resource is the domain of a property named title which has the range “Just Java”. The title property is defined in the Dublin Core namespace.
The above example completes our presentations on how RDF(S) can be translated to O-Telos and back. The previous chapter introduced the ability of translating RDF to O-Telos thus enabling the storing capabilities of the meta database ConceptBase. This chapter now shows how the RDF data stored in ConceptBase can easily be retrieved and presented in RDF.
The Edutella peer described is fully implemented in Java as is the whole EDUTELLA-Project. The actual implementation consists of three parts: the servlet enables a simple user interface, the EdutellaPeer implementation realizes the Edutella peer service and the EdutellaProvider provides the actual query service.
The demo and test servlet running at http://www.cip1.uni-hannover.de :3120/rdf2cb/ runs within a SUN JavaWebServer 2.0. The servlet itself realizes the user interface for testing purposes only thus enabling users to pose RDF-QEL queries in the same way the Edutella peer service will do <?xml version=’1.0’ encoding=’ISO-8859-1’?> <!DOCTYPE rdf:RDF [ ENTITY rdf ’http://www.w3.org/1999/02/22 -rdf-syntax-ns#’ ENTITY a ’http://purl.org/dc/elements/1. 1/’ ]> <rdf:RDF xmlns:rdf="&rdf;"
xmlns:a="&a;"> <rdf:Description rdf:about="http://www.xyz. com/jv.html" a:title="Just Java"/> </rdf:RDF> Example 3.4: The XML serialization of the query answer expressed in RDF and inspecting the respective answers.
Figure 3 shows that the Servlet as well as the Edutella peer
pose EduQuery-objects to the Edutella provider implementation.
The EduQuery-objects contain the queries. They are built using the
classes of the Edutella software package, especially employing the
parser that is based on an adaptation of the Jena RDF parser API [
As shown in figure 3 the ProviderAdapter receives EduQuery objects. In a first step these are translated to O-Telos query objects by the QueryWorker. In a second step the ResponseWorker establishes a connection to the ConceptBase database, poses the query, receives the answer and returns the EduResult objects constructed from ConceptBases’ answer. The ProviderAdapter itself returns the EduResult objects to either the servlet or the Edutella peer which in turn process them as according to their respective needs. 5
The evolving Edutella P2P network combines provider and client peers of various kinds. In this paper we have described a prototypical implementation of a provider peer which provides extended reasoning capabilities for RDF data. The provider peer uses the ConceptBase database which implements the meta modeling language OTelos. Based on this database the basic Edutella services storage and querying are realized: a repository for storing RDF data and query facilities for the stored data.
The storage service uses a translation from RDF(S) to O-Telos and vice versa where property-centered RDF(S) data is translated to and from object-centered O-Telos data. Based on this translation the query service translates RDF-QEL queries to O-Telos query classes and translates the answers to these queries, instances of O-Telos query classes, back into RDF(S) graphs.